温馨提示：另有配套视频版，附带图解演示，观感不同，欢迎到各大视频平台搜索同名标题或【蛋先生说识】
开场
丹尼尔：蛋兄，最近老刷到"Agent = Model + Harness"这个说法，我记得您之前就提到过 Harness（温馨提醒：想回顾的观众可以在各平台搜索"外挂变内置: 大模型工具调用与思维链的能力进化史"），要不今天就接着聊聊这个吧
蛋先生：也行！Harness 的本意是"马具"，把它套在马身上，马力就能变成拉车的动力
丹尼尔：哇，挺形象的！那我懂了，这里的 Harness 就是把大模型的"智力"变成解决实际问题的"生产力"。那像 LangChain 这种智能体框架，就算是一个 Harness 吗？
蛋先生：悟性不错，方向是对的。但 LangChain 还真算不上 Harness------Harness 是夹在模型和真实环境之间的完整运行时，开箱即用。可以有多种交互和集成形式，比如 CLI 的形式 Claude Code；比如 SDK 的形式 Claude Agent SDK，import 一下就能跑起完整的 agent runtime。而 LangChain 这类智能体框架只提供搭 Harness 的零件和抽象，得你自己来组装
丹尼尔：哦，那它都包含哪些功能呢？
蛋先生：它的功能设计大可以参考人类：一个人要自主解决任务，除了靠大脑，还得靠什么？
丹尼尔：直接说吧，最近短视频刷太多，没脑子了^_^"
蛋先生：(-_-;) 还得靠记忆、工具、制度、同事、文档等等。就拿解决一个 bug 来说，光靠大脑转可不够：得查查这个模块之前改过什么（记忆）、得翻翻历史 wiki（文档）、得用编辑器改代码（工具）、得找同事 review（同事）、往主分支合并还得走审批（制度）
丹尼尔：哦，参考人类！好像有点明白了，但还是不太系统
蛋先生：想系统地了解 Harness 的功能，可以参考《Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents》这篇论文，它把生产级 Harness 拆成了七个子系统。接下来咱们就好好聊聊，这七个子系统都是些什么
子系统一：Agent Loop（智能体循环）
丹尼尔：好咧！那第一个是什么？
蛋先生：第一个是 Agent Loop，它是整个系统最核心的中央控制流，其它大部分子系统都是围绕它提供能力支撑的
丹尼尔：那它是借鉴了人类的什么？
蛋先生：我们在处理问题时，大多都是"走一步看一步"。就拿"早上出门找不到小电驴钥匙"来说，可能的排查过程是这样的：
- "多半在昨晚穿的那件外套口袋里" → 翻口袋 → 没有
- "那大概在玄关抽屉里" → 拉抽屉 → 还是没有
- "会不会压根就没带回家？" → 下楼看车 → 钥匙果然插在车上
丹尼尔：嗯，这种"走一步看一步"，在控制上是怎么实现的？
蛋先生：核心就是"推理---行动---观察"的循环
丹尼尔：ReAct 循环？
蛋先生：没错，生产级别的 ReAct 循环
丹尼尔：生产级别？
蛋先生：既然是循环，就得有"停止条件"；某一步执行失败了，得有"失败恢复"；工具之间是串行还是并行，得有"并发调度"；还有消息历史这些状态，也需要"状态管理"
子系统二：LLM Integration（模型接入）
丹尼尔：有点明白了，那第二个呢？
蛋先生：Agent 之所以区别于其它应用，就在于它"带脑子"了。所以子系统二 LLM Integration，解决的就是怎么把"脑子"接进来的问题
丹尼尔：那它是借鉴了......
蛋先生：这个没得借鉴，因为人类的大脑不能换，但 Agent 的大模型不仅可以换，甚至还能同时用多个
丹尼尔：哈哈。那直接说说这个子系统的功能吧
蛋先生：模型接入，要解决的自然是和大模型的通讯问题，一共分为三层
第一层是通信适配层，解决"怎么通讯"的问题。调大模型本质上就是调 API，而各家大模型的 API 五花八门，所以这一层负责处理入参怎么转换、连接怎么建立（认证、SSE 或 WebSocket 等）、出参怎么解析
第二层是上下文提示层，解决"发什么给大模型"的问题，也就是通过 Prompt 组装，把要发给大模型的系统提示词，动态上下文等提示词整理得井井有条
第三层是策略控制层，解决"怎么发才最优"的问题。比如怎么省钱（Prompt Caching）、用哪个模型最合适（Model Routing）、让模型想多深（Thinking / Reasoning Effort）
子系统三：Tools & Actions（工具与行动）
丹尼尔：明白了，接脑子。那第三个呢？
蛋先生：这个就厉害了，它决定了 Agent"能做什么"以及"怎么做"，这就是 Tools & Actions
丹尼尔：展开说说
蛋先生：一静一动
丹尼尔：静是指啥？
蛋先生：静是静态描述，回答的是"能做什么"
第一，得知道有哪些工具，所以需要一份工具清单，也就是工具注册表
第二，得知道每个工具怎么用，所以需要一份"说明书"，包括工具名称、用途，以及入参出参的 schema
丹尼尔：那动呢？
蛋先生：动是执行过程，回答的是"怎么做"
第一，得知道用这个工具安不安全，所以需要权限校验（这里只负责在执行前拦截做校验，具体怎么判，是子系统五的职责）
第二，得知道能不能同时使用多个工具。有些工具一起用会出问题，比如 git commit 和 git push 同时执行就容易冲突，所以得为每个工具声明是否并行安全（至于怎么调度，是子系统一的职责）
第三，得提供工具的执行环境------是直接在本机执行，还是在隔离的沙箱里（决策权在接下来的子系统四）
第四，得知道工具具体怎么执行------是进程内直接调函数，还是通过协议转发给外部服务器（MCP 工具就是后者）
最后，得知道工具返回的结果怎么处理，比如脱敏、格式化、错误处理、写回会话历史等
丹尼尔：那现在主流的工具提供方案，像 MCP 和 Skills，是属于这个子系统吗？
蛋先生：当然不是，这也是最容易误解的地方。该子系统只关心工具的注册和执行，至于工具以哪种方案提供，归后面的子系统七管，咱们到那儿再说
丹尼尔：啊，还是不太明白。一提到工具，我就会自然想到 MCP 和 Skills 啊
蛋先生：就拿 MCP 来说，从 MCP Server 获取工具清单，不是这里的职责，这里只负责把拿到的清单注册到工具注册表里。再比如 Skills 的可执行脚本，本质上只是最基础的 shell 工具的入参，这个子系统只要内置一个 shell 工具（比如 bash），就能执行 Skills 的脚本了
子系统四：Memory & Context（记忆与上下文）
丹尼尔：原来如此，单一职责，说好只管工具就绝不越界。那第四个呢？
蛋先生：第四个是 Memory & Context，主要借鉴了人类的记忆，分为会话记忆和跨会话记忆两种
丹尼尔：说具体点，先从 Memory 开始吧
蛋先生：前面聊到的哪个子系统是跟思维链相关的？
丹尼尔：子系统一 - Agent Loop 啊，你在考我？
蛋先生：这就是会话记忆------你靠回忆咱们刚才聊的内容，才答得上来我的问题
丹尼尔：哦哦！那跨会话记忆呢？
蛋先生：思维链的进化史，还记得一些细节不？
丹尼尔：嘻嘻，还好我有做笔记的习惯，我翻一下
蛋先生：这就是跨会话记忆------你在别的会话里记过一些笔记，当我问到本会话之外的问题时，你就能靠检索笔记来回答。靠着跨会话记忆，agent 会越来越懂你、越来越懂项目、越来越懂环境
丹尼尔：原来如此。那 Context 呢？
蛋先生：Context 决定的，是最终给到大模型看的内容
丹尼尔：它是怎么决定的？
蛋先生：一是获取相关内容，通过检索工具，在跨会话记忆、仓库代码文件等地方检索相关信息；二是加工内容，因为上下文窗口是有限的，得用截断、压缩、摘要等手段确保内容不溢出。所以它的产出，就是上下文中相关的动态提示词部分
子系统五：Safety & Permissions（安全与权限）
丹尼尔：OK，明白了。那第五个呢？
蛋先生：前面提到，工具执行前需要进行权限校验，那具体怎么校验，就是这第五个子系统的职责了------Safety & Permissions（安全与权限）
丹尼尔：哦？那具体是怎么校验的？
蛋先生：围绕"一个动作的执行"全流程设防，一共三道防线：事前拦、事中关、事后查
丹尼尔：事前拦是怎么拦？
蛋先生：完整的审批流程一般是一道"三层闸门"：规则先判 → 规则判不了就 LLM 判 → LLM 也判不了就人类判。判定结果只有三种：ALLOW / DENY / ASK，只有 ASK 会往上升级，特别像人类的逐级"审批"流程
丹尼尔：哦，那所有工具执行的权限校验，都要走这么一套审批吗？
蛋先生：当然不是！还是参考人类：有些事组长就能拍板，直接返回 ALLOW / DENY，不用上报；有些事确实要走满三层、层层上报；还有些事可以跳过前面几层，直接让总监来批。这些规则就叫策略（policy）------它管的是"怎么判"，相当于整条审批链的路由表，决定着审批流程最终怎么走
丹尼尔：那是根据什么来判断的？
蛋先生：除了动作，还有输入------喂给模型的网页、文件里，可能藏着诱导它的指令（间接提示词注入），所以得给这些不可信内容打标记、做扫描，防止"下毒"
丹尼尔：明白了。那事中关呢？
蛋先生：审批通过了，也不能保证模型永远不犯错，所以执行时可能需要把它关进笼子------沙箱隔离，限制它能碰的文件、能访问的网络
丹尼尔：事后查，盲猜就是日志？
蛋先生：没错，所有动作都要留下审计日志，出了事才能追溯
子系统六：Orchestration（编排）
丹尼尔：头脑里 harness 的架构图越来越清晰了，感觉真棒！趁热打铁，第六个是？
蛋先生：是团队协作，也就是把复杂问题拆成多个简单小问题的解决思路------这就是 Orchestration（编排）
丹尼尔：那怎么拆呢？
蛋先生：一种是生成并协调子代理（sub-agent），一种是连接其它的 agent
丹尼尔：无论子代理还是外部 agent，本质上都是与其它 agent 协作。那实际应用中，该怎么决定用哪种呢？
蛋先生：这个简单，就像实现一个方法一样：如果已经有现成的微服务（也就是 agent），直接连接它就行；如果没有，一开始也别过度设计，用最简单的方式，先作为项目里的一个内部方法实现（也就是 sub-agent）。等后来发现很多项目都在用这个方法了，再把它抽成微服务共享出去就可以了
子系统七：Extensibility（扩展性）
丹尼尔：这下舒服多了！就剩最后一个，拿下它就齐活了
蛋先生：刚好到总结的时候了。子系统一提供了主流程，子系统二到六都是在完善主流程的各个环节，而最后这个子系统七，则是对前面六个子系统的扩展。毕竟千人千面，谁也不可能满足所有人的需求，所以需要扩展性------这就是 Extensibility（扩展性）
丹尼尔：具体扩展啥呢？
蛋先生：比如对子系统一的主流程循环，可以通过钩子（hooks）在关键节点上定制逻辑，像每步执行前（PreToolUse）、执行后（PostToolUse）、会话开始和结束等生命周期事件
丹尼尔：那子系统二呢？大脑还能扩展？
蛋先生：可以，比如通过 Provider 插件，接入"新的脑子"
丹尼尔：子系统三应该是加工具吧？
蛋先生：对，比如支持 MCP 协议、增加自定义工具机制，来扩展"能做什么"
丹尼尔：那子系统四，记忆与上下文呢？
蛋先生：比如支持 skills 机制，来扩展"懂什么"
丹尼尔：子系统五安全与权限呢？
蛋先生：比如通过策略（policy）扩展"怎么判"这张审批路由表，也就是 policy as code
丹尼尔：那子系统六编排呢？
蛋先生：比如定义一个专属的 sub-agent，写一份声明式配置文件就够了；再比如通过支持 ACP、A2A 这些协议来连接其它 agent。对了，还有一个"大礼包"机制------插件（plugins），一个插件可以同时打包多个子系统的扩展
预告
丹尼尔：真好，现在算是系统地认识了 Harness。不过我对每个子系统的具体实现方案还挺感兴趣的
蛋先生：这个能讲好多集，咱们慢慢来
丹尼尔：好吧，小期待一下
蛋先生：饭点了，拜拜！
写在最后
看完这七个子系统，你觉得 Harness 还有哪些功能没被提到的？ 或者在你的理解里，Harness 还有哪些活是它该干、这里没覆盖到的？评论区说说呗
都到这了，要不，顺手点赞 / 收藏 / 关注支持下呗？ o(￣▽￣)ｄ
#Agent #Harness #智能体 #Claude Code #MCP #Agent架构 #Agent开发 #智能体框架 #工具调用 #思维链 #SKILL #LangChain #沙箱隔离 #ReAct #上下文工程 #原理 #知识分享 #AI #大模型 #人工智能