/tags/llm/ Recent content in LLM 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/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>