同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法
同一个 Claude，为什么在我手里是智障：agent 能力是乘法，不是加法
给自己的 MCP tool 接好项目管理 API 之后，我冒出一个更大的念头：Claude Code 能读文件、跑测试、看报错、回头改 bug，底层不也是 Claude 吗？我手上有 API key，自己搭个 agent 跑业务流程，应该不难。
两周后，我做出了一个磕磕绊绊的东西。它有时会调工具，有时卡着不动；聊几轮之后，该保留的信息丢了，无关内容却一直塞在 context 里。同样一个 Claude，在 Claude Code 里能连续干活，接进我的应用就像换了个脑子。
我先怪 prompt。改了一周提示词，又加向量检索，在不同模型之间来回切，结果只改善了一点。真正缺的那部分，一直不在 prompt 里。
agent 的能力更接近一场乘法：模型 × harness。任何一边太弱，另一边都救不回来。
我漏掉的是反馈回路
模型本身不会碰文件，也不会执行命令。它只能根据当前输入，决定下一步要调用什么工具。真正读文件、应用修改、运行测试，再把结果送回下一轮的，是外面的 harness。
我最早那版只做了”让模型调用 API”。文件和历史记录怎么选，全靠我一次塞进 prompt；工具失败后，只返回一段原始报错；对话变长了，也没有清理过期信息。模型每一轮都在一堆噪声里重新猜当前状态。
成熟的 coding agent 至少替模型处理了几件事：按任务取相关上下文，执行并校验工具调用，把测试和编译结果送回去，以可控的方式修改文件，并在任务结束前运行验证。模型没有因此变聪明，但它终于能看见自己上一步造成了什么。
我那两周一直在改”它该怎么回答”，实际缺的是”它做完一步后，怎样拿到可靠后果”。没有后果，agent loop 只是连续猜很多次。
模型和 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 无法满足数据隔离或审计要求时，再替换或自托管相关部分；不要因为”团队场景”四个字，就默认必须从零开始。
模型也不能一档用到底
我以前还得出过另一个过头的结论：既然模型是乘数，就永远选最强的，别为 token 降档。
实际要看任务。批量改名、按明确规则补字段，较小模型通常更快也更便宜；架构取舍、陌生领域和隐蔽 bug 才需要更强能力。任务失败时，先看它属于哪一种：漏读文件、没跑测试，是执行深度和 harness 的问题；上下文齐全、验证也做了，仍然稳定地判断错，才该换更强模型。
现在我再看一个”不够聪明”的 agent，会先检查整条链：它拿到了什么，能调用什么，失败如何返回，完成由谁验证。prompt 只是其中一段。
模型决定它可能做到多好，harness 决定这份能力能不能落到当前任务里。