/tags/ai-agent/ Recent content in AI Agent on 星澜 Hugo zh-CN Wed, 01 Apr 2026 09:00:00 +0800 /post/2026/04/01/2026040106/ Wed, 01 Apr 2026 09:00:00 +0800 /post/2026/04/01/2026040106/ <h2 id="引言">引言</h2> <p>Anthropic 和 Codex 的分歧，最近算是公开了。</p> <p>同样都在做 coding agent，但对 harness 的判断，两边已经走出了明显不同的方向。一边是 Anthropic 的工程博客，系统展示了他们怎么把 harness 做得更强、更厚。另一边是 Codex 开源负责人 Michael Bolin 在一场访谈里给出的信号——几乎是反着来的。一个在继续加厚，一个在说别做那么厚。</p> <p>这把一个本来没什么争议的问题顶到了台面上：harness 到底是终局，还是只是中间态？</p> <h2 id="anthropic-在做什么">Anthropic 在做什么</h2> <p>为了让 Claude Code 能稳定跑完长任务、构建完整应用，Anthropic 往 harness 里加了不少重的结构：</p> <ul> <li><code>planner</code>：把一句话需求展开成完整规格</li> <li><code>generator</code>：负责真正去实现</li> <li><code>evaluator</code>：模拟真实用户去跑页面、接口、数据库状态</li> <li><code>context reset</code>：上下文快脏掉的时候直接清空，重新起一个新 agent，通过结构化交接文件把状态接过去</li> </ul> <p>这套路线的核心判断是：模型本身还不够稳，所以得靠更强的外部编排来兜住长任务里的跑偏风险。复杂任务之所以能落地，靠的不是单次生成能力，而是整套控制结构够不够强。</p> <p>说白了就是：模型做事，harness 保证别失控。</p> <h2 id="codex-在说什么">Codex 在说什么</h2> <p>Michael Bolin 在访谈里给出的方向几乎是反过来的。他说他们理想中的 harness 应该尽可能小、尽可能轻。</p> <p>不是说 harness 不重要，而是：不要把太多决策硬编码进外部框架，不要疯狂堆专用工具，不要让模型每走一步都被人类写好的规则牵着走。</p> <p>Codex 的思路更像是给模型一个真实的运行环境——终端、沙盒、必要的上下文连接能力——但探索路径、调用方式、执行策略，尽量让模型自己决定。</p> <p>打个比方：脚手架可以有，但别把它做成一栋楼。因为模型早晚会涨到能自己处理更多东西。</p> <h2 id="两边真正的分歧在哪">两边真正的分歧在哪</h2> <p>表面看是 harness 该做厚还是做薄，但其实两边都没有否认 harness 的价值。他们真正分歧的，是对模型能力曲线的判断不一样。</p> <ul> <li>Anthropic 在回答：模型还不够稳的时候，怎样让复杂任务真的跑起来</li> <li>Codex 在回答：模型越来越强之后，哪些外部结构还值得保留</li> </ul> <p>这不是技术细节的分歧，而是两个不同时间假设下的工程选择。</p> <p>如果模型的大幅提升还很远，Anthropic 那条路就是现阶段最务实的选择。如果模型跃迁来得很快，Codex 那条路是在提醒你：别把过渡期的脚手架做成未来的长期负担。</p> <h2 id="底线">底线</h2> <p>Bolin 也没有说 harness 会彻底消失。他保留了一个底线：环境和安全不退场。</p> /post/2026/03/29/2026032906/ Sun, 29 Mar 2026 15:00:00 +0800 /post/2026/03/29/2026032906/ <h2 id="引言">引言</h2> <p>聊 <code>harness engineering</code>，资料并不少，真正难的是不同文章经常不在同一层说话。</p> <p>Anthropic 和 LangChain 这两篇很适合放在一起看：前者更像在谈长任务架构，后者更像在谈运行时调优。</p> <p>如果前两篇《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》和《<a href="/post/2026/03/29/2026032902/">02. AI Agent 与 Harness：从 Prompt 到 Harness</a>》解决的是概念和背景，那么这一篇要解决的是三件事：</p> <ul> <li>Anthropic 和 LangChain 这两篇文章各自在强调什么</li> <li>它们为什么都把 <code>harness</code> 看得比 prompt 更重要</li> <li>它们的视角有什么共同点，又有什么区别</li> </ul> <p>如果你更关心落地阶段的验证闭环，可以接着读《<a href="/post/2026/03/29/2026032903/">03. AI Agent 与 Harness：V2 Harness 的验证设计</a>》。</p> <h2 id="为什么这两篇文章值得单独拿出来看">为什么这两篇文章值得单独拿出来看</h2> <p>因为它们都把一个过去经常被模糊处理的问题说透了：</p> <p><code>模型能力强，不等于系统就稳定。</code></p> <p>过去很多讨论会把注意力放在：</p> <ul> <li>模型版本</li> <li>提示词技巧</li> <li>上下文长度</li> <li>是否支持工具调用</li> </ul> <p>但这两篇文章真正强调的是：</p> <ul> <li>工具怎么组织</li> <li>上下文怎么管理</li> <li>失败怎么被发现</li> <li>系统怎么返工</li> <li>长任务怎么防止熵增</li> </ul> <p>也就是说，它们讨论的重点不是“模型会不会”，而是“系统能不能稳定做完”。</p> <h2 id="anthropic-那篇到底在讲什么">Anthropic 那篇，到底在讲什么</h2> <p>文章原文：</p> <ul> <li><a href="https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents">Effective harnesses for long-running agents</a></li> </ul> <h3 id="1-它说的-harness-很重">1. 它说的 harness 很重</h3> <p>Anthropic 那篇最重要的一个信号是：<br> 他们说的 harness，不是几个 prompt，不是一份 <code>AGENTS.md</code>，也不是若干个 tool 描述。</p> /post/2026/03/29/2026032905/ Sun, 29 Mar 2026 14:00:00 +0800 /post/2026/03/29/2026032905/ <h2 id="引言">引言</h2> <p>上一篇讲的是第一类场景：用现成 agent 产品时，团队怎么把自己的 harness 搭好。</p> <p>这篇讲第二类：如果是自己开发退款 agent、审批 agent、客服分诊 agent，<code>agent harness</code> 到底长什么样？</p> <p>这是《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》里提到的第二类场景——不是在现成 agent 产品外面加一层团队规范，而是自己从头搭一套业务 agent 系统。</p> <p>对退款、审批、客服分诊、工单流转这类系统来说，第一步通常不是先打磨 prompt，而是先把流程图画出来。 图一旦清楚，第一版系统骨架往往也就跟着出来了。</p> <h2 id="为什么先画流程图再谈-agent">为什么先画流程图，再谈 agent</h2> <p>这当然不是说：</p> <p><code>流程图 = 代码</code></p> <p>而是说，对于退款、审批、分诊、风控这类业务 agent，你一旦能把下面几件事画清楚，第一版系统骨架其实就已经出来了：</p> <ul> <li>有哪些节点</li> <li>节点之间怎么流转</li> <li>哪些节点必须确定性执行</li> <li>哪些节点可以交给模型判断</li> <li>哪些地方要加人工接管</li> <li>哪些地方要加验证和返工</li> </ul> <p>很多团队一开始觉得自己是在“做 AI agent”，后来真正落地时会发现，第一步其实更像：</p> <ul> <li>画流程图</li> <li>画状态流转</li> <li>画工具调用图</li> <li>画失败回退路径</li> </ul> <p>这些图一旦清楚了，agent harness 的大部分骨架也就跟着清楚了。</p> <p><code>能画出流程图，不代表已经把 agent 写完了；但通常已经走到了“能开始写 agent harness”的阶段。</code></p> <h2 id="graph-在表达什么">Graph 在表达什么</h2> <p>这里说的 <code>graph</code>，不要只把它理解成某个具体框架的对象。<br> 它更广义地指：</p> <ul> <li>节点</li> <li>边</li> <li>状态</li> <li>路由规则</li> <li>重试和返工路径</li> </ul> <p>一个业务 agent 的 graph，通常至少会包含几类节点：</p> <ul> <li><code>LLM 节点</code> <ul> <li>负责意图理解、信息提取、回复生成、某些开放判断</li> </ul> </li> <li><code>工具节点</code> <ul> <li>查订单、查政策、调退款接口、写工单、发通知</li> </ul> </li> <li><code>规则节点</code> <ul> <li>权限判断、风控判断、政策判断</li> </ul> </li> <li><code>验证节点</code> <ul> <li>检查动作结果是否真的生效</li> </ul> </li> <li><code>人工节点</code> <ul> <li>升级审批、转人工处理、人工兜底</li> </ul> </li> </ul> <p>这时 graph 真正表达的，不只是“业务流程长什么样”，还包括：</p> /post/2026/03/29/2026032904/ Sun, 29 Mar 2026 13:00:00 +0800 /post/2026/03/29/2026032904/ <h2 id="引言">引言</h2> <p>前面两篇篇把概念、演进背景和验证设计铺开了，从这篇开始落地。</p> <p>《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》里提到两类场景，这篇先讲第一类：对大多数团队来说，眼前更现实的任务并不是马上造一套业务 agent 系统，而是先把 <code>Codex</code>、<code>Claude Code</code> 这类现成 agent 用稳。</p> <p>这时候真正需要补的，就是团队自己的那层 harness——仓库里的这些东西：</p> <ul> <li>repo instructions</li> <li>skills</li> <li>MCP 使用约定</li> <li>验证命令</li> <li>交付格式</li> <li>review / CI workflow</li> </ul> <p>放到一个典型的后端团队里，这件事会变得很具体：</p> <ul> <li>Web 框架用 <code>gin</code></li> <li>数据层用 <code>gorm</code></li> <li>缓存用 <code>redis</code></li> <li>已经有链路追踪</li> <li>也能通过 MCP 查日志、查 traces、查数据库</li> </ul> <p>问题也会跟着收敛成一句话：</p> <p><code>在这种团队里，怎么把默认工作方式写成 agent 也能稳定遵守的仓库规则？</code></p> <h2 id="团队上下文要写清楚">团队上下文要写清楚</h2> <p>很多团队装了 MCP、写了几句提示词，就以为自己已经在做 harness。<br> 但如果 agent 连“这个仓库到底怎么工作”都不知道，它其实还是进不了团队的真实语境。</p> <p>所以第一步不是堆工具，而是把上下文写明白。</p> <p>像一个 <code>gin + gorm + redis</code> 的 Go 团队，至少要把这些共识显式化：</p> <ul> <li>项目目录结构</li> <li>HTTP 层怎么组织</li> <li>service / repository 怎么分层</li> <li><code>gorm</code> 查询和事务怎么写</li> <li><code>redis</code> key 命名、TTL 和失效策略怎么定</li> <li>trace 和日志字段怎么打</li> <li>什么命令算基本验证</li> <li>什么结果才算 done</li> </ul> <p>这些东西如果只存在于资深同事脑子里，agent 是用不稳的。</p> /post/2026/03/29/2026032903/ Sun, 29 Mar 2026 12:00:00 +0800 /post/2026/03/29/2026032903/ <h2 id="引言">引言</h2> <p>前面两篇把概念和演进背景铺开了，但真正落到工程里，最难的一层往往不是”怎么让 agent 开始做事”，而是”怎么确认它真的做成了”。</p> <p>很多团队已经有 prompt、skill、<code>AGENTS.md</code>、MCP 和常用工具，agent 也确实能开始干活。<br> 问题通常出在交付阶段：测试会漏跑，状态会漏校验，模型会以为自己完成了，系统却没有真的过关。</p> <p>所以这一篇只想回答一个非常落地的问题：</p> <p><code>验证阶段的 harness，到底应该怎么设计？</code></p> <p>尤其是下面这个追问：</p> <ul> <li>coding agent 里，我们已经会在 <code>AGENTS.md</code>、<code>CLAUDE.md</code>、skill 里要求“写完要补测试并运行”，但模型还是会偶尔忘记</li> <li>那业务 agent 的验证到底该怎么做</li> <li>动作后验证到底是什么</li> <li>它在 <code>agent harness</code> 里怎么落，以及在仓库规则、验证命令和 CI 流程里怎么体现</li> </ul> <p>如果你还没看前面两篇，可以先从《<a href="/post/2026/03/29/2026032901/">01. AI Agent 与 Harness：概念梳理</a>》和《<a href="/post/2026/03/29/2026032902/">02. AI Agent 与 Harness：从 Prompt 到 Harness</a>》开始，再回来看这一篇会更顺。</p> <p>很多团队其实已经有了 <code>V1</code> 级别的 agent setup，但还没有真正进入 <code>V2 agent harness</code>。</p> <p>比如开发团队里，大家已经开始做这些事：</p> <ul> <li>指定统一使用 <code>Codex</code> 或 <code>Claude Code</code></li> <li>写 <code>AGENTS.md</code> / <code>CLAUDE.md</code></li> <li>把代码规范、框架规范、提交流程整理成 skill</li> <li>推荐安装 <code>dbhub MCP</code>、<code>GitHub MCP</code>、<code>fetch MCP</code></li> <li>固定常用命令、目录结构和交付格式</li> </ul> <p>这些都很有价值，而且已经远远不只是“写好提示词”了。<br> 但它们更多解决的是：</p> <ul> <li>怎么给 agent 足够的上下文</li> <li>怎么统一团队使用方式</li> <li>怎么让 agent 更容易做事</li> </ul> <p>这更多还是：</p> /post/2026/03/29/2026032902/ Sun, 29 Mar 2026 10:00:00 +0800 /post/2026/03/29/2026032902/ <h2 id="引言">引言</h2> <p>这几年看 AI 相关讨论，一个很明显的变化是：大家聊的话题一直在往外扩。</p> <p>最开始聊的是 <code>prompt</code>，后来开始聊 <code>context</code>、<code>tool calling</code>、<code>workflow</code>，再到这两年越来越常见的 <code>harness engineering</code>。</p> <p>表面上看，好像只是名词越来越多。 但如果把这些讨论放回工程语境里，它们其实指向的是同一个变化：任务越来越像真实系统问题，单次提示词已经不够解释 agent 的表现了。</p> <p>这篇文章想回答的，就是这个问题：</p> <p><code>为什么今天大家会从 prompt engineering，一路谈到 context engineering，最后谈到 harness engineering？</code></p> <p>如果你更想继续往后读：</p> <ul> <li>验证落地篇：<a href="/post/2026/03/29/2026032903/">03. AI Agent 与 Harness：V2 Harness 的验证设计</a></li> <li>工程落地篇：<a href="/post/2026/03/29/2026032905/">05. AI Agent 与 Harness：Agent Harness、Graph 与退款 Agent</a></li> <li>团队落地篇：<a href="/post/2026/03/29/2026032904/">04. AI Agent 与 Harness：Repo Instructions、Skills 与团队工作流</a></li> <li>外部文章拆解：<a href="/post/2026/03/29/2026032906/">番外. AI Agent 与 Harness：Anthropic 和 LangChain 的 Harness Engineering</a></li> </ul> <p><code>harness engineering</code> 之所以变成热词，不是因为大家突然发明了一个新名词，而是因为任务复杂度真的变了。</p> <ul> <li>当任务还只是一次性问答时，prompt 就已经很有用</li> <li>当任务开始跨多轮、多工具、多状态、多系统时，光靠 prompt 就不够了</li> <li>一旦目标从“回答得像”变成“真的做完并且做对”，系统设计就自然会压过单次提示词技巧</li> </ul> <p><code>AI 讨论的重心，正在从“怎么让模型更会说”，转向“怎么让系统更稳定地做完”。</code></p> <h2 id="为什么今天大家会频繁谈-harness">为什么今天大家会频繁谈 harness</h2> <p>过去很多讨论会把注意力放在：</p> <ul> <li>模型版本</li> <li>提示词技巧</li> <li>上下文长度</li> <li>是否支持工具调用</li> </ul> <p>这些当然都重要。<br> 但一旦模型开始进入真实业务系统，大家很快就会撞上另一类问题：</p> /post/2026/03/29/2026032901/ Sun, 29 Mar 2026 09:00:00 +0800 /post/2026/03/29/2026032901/ <h2 id="引言">引言</h2> <p>最近一直在反复想几个词：<code>agent</code>、<code>harness</code>、<code>skill</code>、<code>tool</code>、<code>MCP</code>、<code>context</code>、<code>memory</code>。<br> 它们在视频、推文、产品宣传、框架文档里经常被混着说，结果就是每个词都像懂了，又都不算真懂。</p> <p>这篇文章想做的事很简单：把这些词放回工程语境里，先理顺它们之间的关系，再把这组文章的阅读顺序摆清楚。</p> <h2 id="总结">总结</h2> <ul> <li><code>Model / LLM</code> 是底层推理与生成能力，不等于完整 agent</li> <li><code>Agent</code> 是带有目标、状态、工具使用和多步行动能力的 LLM 系统</li> <li><code>Harness</code> 不是某个单独组件，而是让 agent 稳定完成任务的整套工程化装置</li> <li><code>Skill</code>、<code>Tool</code>、<code>MCP</code> 往往都是 harness 的组成部分，但它们单独都不等于 harness</li> <li><code>Prompt engineering</code> 解决的是“怎么说”，<code>context engineering</code> 解决的是“让模型看到什么”，<code>harness engineering</code> 解决的是“怎么让整个系统稳地做完”</li> </ul> <p>压成一句话就是：</p> <p><code>model 负责想，agent 负责持续做，harness 负责让它做得稳、做得可控。</code></p> <h2 id="概念地图">概念地图</h2> <ul> <li><code>Model</code> <ul> <li>提供理解、推理、生成能力</li> </ul> </li> <li><code>Prompt</code> <ul> <li>决定你怎么和模型说话</li> </ul> </li> <li><code>Context</code> <ul> <li>决定当前这一轮让模型看见什么</li> </ul> </li> <li><code>Memory</code> <ul> <li>决定哪些经验和状态可以跨轮次复用</li> </ul> </li> <li><code>Tool</code> <ul> <li>决定 agent 能调用哪些外部能力</li> </ul> </li> <li><code>MCP</code> <ul> <li>决定外部系统如何以统一方式接进来</li> </ul> </li> <li><code>Skill</code> <ul> <li>决定一类任务该按什么方法做</li> </ul> </li> <li><code>Agent</code> <ul> <li>决定系统是否能围绕目标持续行动</li> </ul> </li> <li><code>Harness</code> <ul> <li>决定这个 agent 最终能不能稳定、可控、可交付</li> </ul> </li> </ul> <p>从工程视角，三者的包含关系更像：</p> <p><code>harness 包含 agent，agent 使用 model</code></p> <p>也就是：</p> <ul> <li><code>model</code> 是能力底座，是 agent 的推理内核</li> <li><code>agent</code> 是基于 model 搭起来的行动闭环：<code>model + state + tool use + planning + action loop</code></li> <li><code>harness</code> 是把整个 agent 包裹起来的工程装置：上下文、工具、权限、验证、返工、观测——都在里面</li> </ul> <h2 id="modelpromptcontextmemory-到底是什么关系">Model、Prompt、Context、Memory 到底是什么关系</h2> <p><code>Model</code> 比较像大脑。</p>