第8章 Tool与Code Execution：智能体如何触及真实世界
前两章解决的是智能体在行动之前应该掌握什么。第6章讨论意图与契约，明确任务目标、约束和验收标准；第7章讨论上下文工程，解决相关信息如何被组织、筛选并及时提供给智能体。但一个只能理解和生成文本、却无法作用于外部环境的智能体，对软件工程的价值仍然有限。真正让智能体从对话工具转变为工程协作者的，是它能够读取和修改文件、执行命令、运行测试、调用外部服务，也就是本章所讨论的工具使用与代码执行（Code Execution）能力。
这种能力同时也是智能体风险最集中的位置之一。第5章已经指出，提示注入的攻击链最终往往要落实到某一次具有实际影响的工具调用；与此同时，智能体一旦接入更多外部工具，也意味着其依赖的软件、服务和数据边界随之扩大，供应链风险和权限管理问题也会更加突出。因此，本章关注的并不是“如何让智能体调用更多工具”，而是一个更基础的工程问题：当智能体获得作用于真实环境的能力之后，应该通过什么机制约束这种能力，使其既能够发挥价值，又不会因为一次错误决策而造成不可接受的后果。
本章首先从工具使用与Code Execution的基本机制出发，说明工具为什么不仅是能力接口，也是新的风险边界；随后讨论MCP如何将不同系统的专有集成抽象为相对通用的工具适配机制，以及Code Execution为什么需要区别于普通工具调用的独立信任模型。在此基础上，本章进一步讨论沙箱与审批构成的双轴控制机制，以及Hooks如何在模型决策之外提供确定性的检查与拦截能力，最后回到最小权限和执行环境隔离这一更具普适性的工程原则。
读完本章，读者应当能够理解几个前面章节留下的问题：为什么第5章讨论的提示注入防御最终必须落实到工具权限与执行边界；为什么第6章提到的AGENTS.md和CLAUDE.md只能提供指导，无法构成确定性的安全约束；为什么Planning Mode所声称的“只读”在部分工具中仍可能只是提示层面的限制，以及为什么真正可靠的控制必须建立在模型之外的权限、沙箱和执行环境机制上。换句话说，前面几章解决的是“智能体应该知道什么、应该如何理解任务”，本章解决的则是“智能体在理解之后究竟被允许做什么”。