工具：Agent 的能力边界
本文是「企业级应用中 Harness Engineering 的实践与思考」系列的第 9 篇。
工具让 Agent 从对话走向工作
在生成式 AI 刚开始进入软件开发时，AI 更像是一个聊天窗口里的顾问。人需要把需求、代码片段、报错和上下文复制进去，再把 AI 给出的建议、解释或示例代码复制回项目中。AI 可以帮助思考，但它并没有真正进入开发现场。
当 AI 开始拥有基本工具之后，情况就明显不一样了。它可以读取文件，可以修改文件，可以搜索代码，可以运行命令。fs read、fs write、shell、search 这些看起来很基础的能力，让 AI 不再只是回答问题，而是开始能够直接参与开发。
今天的 agentic 开发工具，默认能力已经更强。很多工具已经内置了文件读写、命令执行、代码搜索、patch、浏览器操作等能力。这些能力让 Agent 更容易理解项目，也让开发变得顺畅很多。
但这仍然不够。
企业级应用的开发现场里，还有大量信息和能力不在默认工具里。Agent 可能看不到 Figma 里的设计稿，读不到 Slack 或 Google Drive 里的历史讨论，不知道 issue 系统里的上下文；它也可能“能”检查代码格式，“能”判断测试是否合理，“能”推测覆盖情况，但这些事情如果只依赖模型本身，就不够稳定，也会浪费宝贵的 Context Window。
这就是工具出现的地方。
这里说的工具，是模型之外，用来扩展 Agent 感知、行动和验证能力的工程机制。它们让 Agent 能看到模型本来看不到的东西，能执行模型本身无法稳定完成的动作，也能用更可靠的方式验证模型生成的结果。
工具大致可以分成几类。
第一类，是连接外部系统的工具，常见形式是 MCP。比如 Figma 让 Agent 读取设计，Playwright 让 Agent 操作浏览器，Slack 或 Google Drive 让 Agent 接触散落在团队协作工具里的上下文。
第二类，是传统软件工程工具。比如 git、Java、Gradle、Docker、lint、test runner、Jacoco、SonarQube。它们不是 AI 时代的新发明，但在 agentic 开发里，它们成为 Agent 稳定执行和验证工作的基础。
第三类，是项目定制工具。比如 skill、script、自定义检查脚本、生成脚本、状态同步脚本。它们通常来自项目中反复出现的问题：某个检查总要做，某种报告总要生成，某类状态总要同步，于是被沉淀成工具。
工具必须跟随 Agent 的职责边界
工具提供能力，所以很容易让人产生一个直觉：工具越多，Agent 越强。
但在 Harness Engineering 中，工具不是越多越好。工具说明会进入 Context，工具结果会进入 Context，工具选择本身也会消耗 Agent 的注意力。工具越多，Agent 越容易在不该使用的工具之间摇摆，也越容易把无关工具的结果带进当前任务。
更重要的是，工具意味着行动能力。读文件、写文件、运行命令、访问外部系统、修改状态、触发部署，这些都不是中性的能力。一个 Agent 拿到不属于自己职责的工具，就更容易越界，也更容易造成不可控的结果。
所以，工具必须跟随 Agent 的职责边界。Agent 的职责定义了它应该拥有哪些能力，也定义了它不应该碰哪些工具。
Dev Agent 需要开发、构建、运行和 git 相关工具，因为它要把需求实现成代码。QA Agent 需要测试框架、Playwright、curl、数据库工具，因为它要验证行为。Code Reviewer Agent 需要 lint、typecheck、static analysis 和自定义检查脚本，因为它要审查代码质量和工程风险。BA Agent 和 TL Agent 需要浏览器、Figma、Google Drive、代码阅读工具，因为它们要帮助人分析需求、设计和技术约束。PM Agent 需要读取状态、整理报告、调度 Agent 的能力，因为它要帮助人管理 workflow。
从工具的角度回看 Agent 的各司其职，也会更容易理解为什么 Agent 不应该随意越界。QA Agent 不只是因为职责上不该改代码，更是因为它没有 Dev Agent 那套开发、构建、提交和实现追踪工具；Dev Agent 不只是因为职责上不该替 QA 做验证，更是因为它没有 QA Agent 那套测试设计、浏览器验证、测试数据构造和测试报告工具；Code Reviewer Agent 不只是因为职责上不该重新实现，更是因为它的工具主要用来暴露代码质量和工程风险，而不是推进功能开发。
一个 Agent 没有完成另一个 Agent 工作所需的工具，就不应该轻易越过自己的职责边界。工具让职责变得真实，也让边界变得具体。
从这个角度看，Agent 不只是由 prompt 和 Context 定义，也由它能使用的工具定义。同一个模型，拿到不同工具，就会成为不同的执行体。职责不同，工具不同；工具不同，能力边界也不同。
工具是对抗中的武器
Agent 面对同样的职责，有工具和没有工具，执行起来差别很大。没有工具时，Agent 只能依靠阅读、推理和自我描述来判断问题；有工具时，很多判断会变成可执行、可重复、可验证的工程结果。
这种差异在对抗流程中最明显。Dev Agent、Code Reviewer Agent、QA Agent 都可以说自己做了检查，但如果没有工具，很多检查仍然停留在 Agent 的主观判断里。有了工具，检查就会变成更稳定的证据。
工具的第一个特点是高效。lint、typecheck、test runner、coverage、build、Playwright 这些工具可以直接执行并给出结果，不需要 Agent 在 Context Window 里反复推理。它们节约的不只是时间，也节约 Agent 的注意力。
工具的第二个特点是精准。不同工具服务于不同目标：lint 检查规则，SAST 暴露安全风险，Jacoco 检查覆盖率，SonarQube 暴露复杂度、重复和坏味道，Playwright 验证真实交互，自定义脚本检查项目特定问题。工具不会把一个明确检查讲成一段泛泛而谈的建议。
工具的第三个特点是无情。Agent 会解释，也会辩解；更重要的是，Agent 之间是会互相影响、互相说服的。Dev Agent 可能把一个没有意义的测试包装成“这里只是 smoke test”“这里不重要”“后续会补”。如果只是让另一个 Agent 看，它也可能被这些解释带过去。
但工具不会被说服。一个没有意义的测试，比如 expect(true).toBe(true)，或者只检查对象 not null，在覆盖率、mutation testing、自定义检查脚本面前，没有意义就是没有意义，覆盖不到就是覆盖不到，规则不通过就是不通过。
这也是工具在对抗中最重要的价值：它把一部分质量要求变成不可协商的事实。Agent 可以讨论原因，可以提出修复方案，但不能靠解释绕过工具暴露出来的问题。
当然，工具是对抗的武器，不是对抗本身。工具能够暴露信号，但信号仍然需要 Agent 和人理解、判断、修复和沉淀。真正的对抗，仍然来自不同职责、不同标准和不同 Context 下的检查。
人负责准备工具和管理权限
工具不会自动成为 Harness 的一部分。哪些能力应该交给工具，哪些知识应该沉淀成 skill，哪些重复动作应该写成 script，哪些工具应该交给哪个 Agent，使用时是默认允许还是需要确认，都需要人来判断。
人的第一项工作，是为 Agent 配备合适的工具。合适的意思有两层：一方面，工具要足够支撑 Agent 高效完成职责；另一方面，工具不能超过 Agent 的职责范围。工具不足，Agent 就只能靠猜、靠解释、靠不稳定的模型判断；工具过界，Agent 就可能做出不该做、也无法承担后果的动作。
人的第二项工作，是把反复出现的知识和流程沉淀成工具。这个工具不一定要从零开始写，也可能是人基于经验找到的已有工具，然后把它接入 Harness。一个检查总是要做，就应该沉淀成脚本；一种报告总是要生成，就可以沉淀成 skill；一种质量问题反复出现，就应该考虑自定义规则或检查工具；一个步骤总是被 Agent 忘记，就应该进入 handbook、workflow 或自动化工具链。
人的第三项工作，是管理工具权限。权限至少有两层含义：第一层是能不能使用这个工具，第二层是在什么范围内使用这个工具。读文件、写文件、运行命令、访问外部系统、修改状态、触发发布，都需要不同的权限策略。有些工具可以默认允许，有些工具必须使用时询问，有些工具只能在特定 Agent 或特定 workflow 阶段使用。同样是删除文件，删除项目内生成的临时文件，和删除项目外目录里的文件，权限含义完全不同；同样是访问外部系统，读取文档和修改线上配置也不是一回事。工具权限如果不和范围绑定，就会把 Agent 的能力边界放得过宽。
所以，工具权限必须和职责对等。人不是简单地给 Agent “更多能力”，而是为 Agent 准备刚好足够完成职责的能力，并确保这些能力被放在可控的边界里。
回到 Harness：工具是 Agent 的手和眼睛
回到 Harness，工具是 Agent 的手和眼睛。它让 Agent 能看见模型本身看不见的内容，也让 Agent 能执行模型本身做不到、做不稳，或者不该只靠模型完成的动作。
工具为 Agent 提供了强大的能力。它让 Agent 能更高效地读取信息、修改项目、调用系统、执行检查、验证结果，也让很多原本依赖模型推理的事情，变成更稳定、更准确、更可重复的工程动作。
但这种强大本身也是危险的。
如果在错误的时间、错误的范围内，由错误的 Agent 使用了错误的工具，后果就可能失控。一个本来只应该阅读上下文的 Agent，可能修改了不该修改的文件；一个本来只应该验证行为的 Agent，可能越界改了实现；一个本来只应该在本地运行的工具，可能触碰了真实系统或真实数据。
所以，好的 Harness 不是给 Agent 无限工具，而是让 Agent 在职责边界内获得足够趁手、可靠、受控的工具。工具要让 Agent 做得更快、更准，也要防止 Agent 在不该行动的地方行动。
工具不是 Harness 的附属品，而是 Harness 控制 Agent 行动能力的重要部分。它既决定 Agent 能看见什么，也决定 Agent 能碰什么；既扩展 Agent 的能力，也定义 Agent 的边界。
