--- title: "同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法 | 行开心的颠倒世界" description: "同一个 Claude，接进不同应用后表现可能天差地别。模型决定能力上限，harness 提供上下文、工具和反馈回路；真正该自建的是业务层，不是从零重写运行时。" canonical: "https://xingkaixin.me/posts/agent-harness-not-model/" language: "zh-CN" --- # 同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法 同一个 Claude，接进不同应用后表现可能天差地别。模型决定能力上限，harness 提供上下文、工具和反馈回路；真正该自建的是业务层，不是从零重写运行时。 2026年7月22日·1,279 字·4 分钟 [Agentic](https://xingkaixin.me/tags/Agentic/)[AI架构](https://xingkaixin.me/tags/AI%E6%9E%B6%E6%9E%84/)[Claude Code](https://xingkaixin.me/tags/Claude%20Code/)[系统设计](https://xingkaixin.me/tags/%E7%B3%BB%E7%BB%9F%E8%AE%BE%E8%AE%A1/) ![同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法](https://xingkaixin.me/cover/agent-harness-not-model.webp) 给自己的 MCP tool 接好项目管理 API 之后，我冒出一个更大的念头：Claude Code 能读文件、跑测试、看报错、回头改 bug，底层不也是 Claude 吗？我手上有 API key，自己搭个 agent 跑业务流程，应该不难。 两周后，我做出了一个磕磕绊绊的东西。它有时会调工具，有时卡着不动；聊几轮之后，该保留的信息丢了，无关内容却一直塞在 context 里。同样一个 Claude，在 Claude Code 里能连续干活，接进我的应用就像换了个脑子。 我先怪 prompt。改了一周提示词，又加向量检索，在不同模型之间来回切，结果只改善了一点。真正缺的那部分，一直不在 prompt 里。 **agent 的能力更接近一场乘法：模型 × harness。任何一边太弱，另一边都救不回来。** ![Agent 能力公式：Model × Harness](https://xingkaixin.me/posts/images/agent-harness-not-model/agent-harness-not-model-01.webp) ## 我漏掉的是反馈回路 模型本身不会碰文件，也不会执行命令。它只能根据当前输入，决定下一步要调用什么工具。真正读文件、应用修改、运行测试，再把结果送回下一轮的，是外面的 harness。 我最早那版只做了”让模型调用 API”。文件和历史记录怎么选，全靠我一次塞进 prompt；工具失败后，只返回一段原始报错；对话变长了，也没有清理过期信息。模型每一轮都在一堆噪声里重新猜当前状态。 成熟的 coding agent 至少替模型处理了几件事：按任务取相关上下文，执行并校验工具调用，把测试和编译结果送回去，以可控的方式修改文件，并在任务结束前运行验证。模型没有因此变聪明，但它终于能看见自己上一步造成了什么。 我那两周一直在改”它该怎么回答”，实际缺的是”它做完一步后，怎样拿到可靠后果”。没有后果，agent loop 只是连续猜很多次。 ![Harness 反馈回路](https://xingkaixin.me/posts/images/agent-harness-not-model/agent-harness-not-model-02.webp) ## 模型和 harness 还会互相影响 “模型 × harness”不是一个精确公式。两边也并非互不相干。 Armin Ronacher 最近记录过一个很具体的问题：新的 Claude 模型在 Pi 里调用编辑工具时，正文改动是对的，却会在嵌套参数里添加 schema 不允许的字段。旧模型没有这个毛病，开启 strict tool invocation 后问题又消失了。 这件事说明，模型可能已经适应了某套常见工具形状和容错方式。换一个 harness，即使 schema 写得没错，也可能落在模型不熟悉的分布外。harness 不能只提供工具，还要验证参数、保留失败轨迹，并用真实任务持续测模型与工具是否匹配。 所以”同一个模型”并不保证表现相同。它接收到什么上下文，工具长什么样，失败以后能不能得到准确反馈，都会改变最终结果。 ## 别从零重写不属于你的那一层 我后来停掉了自己造通用 agent runtime 的计划，把业务接回成熟的运行时。原来两周没跑通的流程，一个下午就通了。 这不等于团队什么都不该自建。真正值得拥有的是贴着业务的那一层：任务从哪里来，哪些数据能读，什么动作需要确认，结果怎么验收，session 和工具失败怎样回放。这些规则决定 agent 能不能进入真实工作流，也不会被一个通用产品替你想清楚。 至于 agent loop、文件工具、权限确认和会话管理，已经有 Agent SDK、Managed Agents、Pi、OpenCode 这类现成基础。除非你的产品本身就在卖 harness，否则从 API 的 `while` 循环重新造一遍，通常是在推迟真正的业务。 团队需要掌握的是控制权，不是每一行运行时代码。现成 harness 无法满足数据隔离或审计要求时，再替换或自托管相关部分；不要因为”团队场景”四个字，就默认必须从零开始。 ![自建 vs 接入成熟 Harness + 自建业务层](https://xingkaixin.me/posts/images/agent-harness-not-model/agent-harness-not-model-03.webp) ## 模型也不能一档用到底 我以前还得出过另一个过头的结论：既然模型是乘数，就永远选最强的，别为 token 降档。 实际要看任务。批量改名、按明确规则补字段，较小模型通常更快也更便宜；架构取舍、陌生领域和隐蔽 bug 才需要更强能力。任务失败时，先看它属于哪一种：漏读文件、没跑测试，是执行深度和 harness 的问题；上下文齐全、验证也做了，仍然稳定地判断错，才该换更强模型。 现在我再看一个”不够聪明”的 agent，会先检查整条链：它拿到了什么，能调用什么，失败如何返回，完成由谁验证。prompt 只是其中一段。 **模型决定它可能做到多好，harness 决定这份能力能不能落到当前任务里。** ## 版权声明 作者 XingKaiXin 标题 同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法 发布时间 2026年7月22日 文章链接 [https://xingkaixin.me/posts/agent-harness-not-model/](https://xingkaixin.me/posts/agent-harness-not-model/) 本作品采用[CC BY-NC-ND 4.0 DEED](https://creativecommons.org/licenses/by-nc-nd/4.0/deed.zh-hans)许可。 导览 展开导览