约束不是缺陷，约束是可靠性的来源

2026-3-31

分享一篇有收获的文章。

从《从 Claude Code 看 Harness Engineer 的设计》

摘取几段原文：

更反直觉的一面是：MCP 工具集的设计，也是在主动限制 Claude 的行动范围。Claude 没有 delete_user_data 这个工具，这个操作就在技术层面不可能发生——不是因为你在 prompt 里写了"不要删除用户数据"，而是因为这个能力根本不存在于工具集里。能力边界即架构边界。这和软件工程里的最小权限原则是同一件事，只是被应用到了 Agent 的工具设计上。

好的 MCP 工具在服务端完成信息筛选，只返回 Claude 这次真正需要的内容。工具的出口设计和入口设计同样重要

但你仍然会偶尔遇到：Claude 说"完成了"，但你一检查，测试没有跑，或者跑了错误的测试集。

原因在于："请确保测试通过"是语言请求，而不是机械约束。 语言请求的可靠性是概率性的，在长任务的末尾、context 被大量消耗之后，它的权重会被稀释。Claude 不是故意不遵守，而是在复杂推理链的末端，它"觉得"应该没问题就声明完成了。

Hook 解决这个问题。

最近在工作中，总是会遇到Claude觉得任务完成了，但实际上还没有。遇到困难了，就总想走捷径，草草了事。每当Context window 快达到上限了就开始焦虑，想快速结束任务。通过读这篇文章意识到，Hook可能是解决这个问题的方案。

当然，印象最深刻的是，"约束不是缺陷，约束是可靠性的来源。"这句话

一个工具集只有五个工具的 Subagent，比一个工具集有五十个工具的 Subagent 更可靠——不是因为能力不够，而是因为出错的可能路径更少。

我常常想给Agent增加工具，增加视觉能力，但必须要深刻的意识到，每增加一个能力，在任务完成时间，词元（紧跟时事）消耗量上就要做出妥协。也许更加应该重视的是，思考当前的Agent里面有哪些工具是一定要的？如果去掉这部分能力，Agent还能不能正常运行？（想起来张小珺和Peak Ji的访谈）