https://x.com/i/article/2109260138750365696
哥伦比亚大学 Agentic Engineering 第 5 讲「Agent tools in pictures」：11 章 221 分钟讲透 Agent 工具
Lecture 5: Agent tools in pictures
主题：哥伦比亚大学 COMS W4995 Agentic Engineering 课程的第 5 讲「Agent 的工具」（Agent tools in pictures） ，工具是什么、一次调用如何发生、把工具交给 agent 的五种方式，以及随之而来的工程判断。整讲约 221 分钟，结构如同一本小书：从最小的真理出发，一层层向上构建，每章配测验与文献出处。
关于「COMS W4995 Agentic Engineering」的解读在这里：
贯穿全讲的核心命题
「模型写订单，程序做菜。」 这是开篇的第一性原理：语言模型从不执行工具，它只生成一段结构化文本（工具名 + 参数）。真正决定调用是否发生、执行代码、返回结果的，是模型外围的 harness（执行框架）：解析、校验、鉴权、执行、回填结果的那段程序。
这一命题的推论是全课的安全观：提示词不是锁，代码才是锁。 在 prompt 里写「永远不要删生产数据」只是增加文本，不是权限控制。Claude Code 文档的原话：「权限规则由 Claude Code 执行，而不是由模型执行。」由此引出每个工具必然带出的四个问题及其归属者：
1.模型看到什么？ → 契约（contract：名称、描述、JSON Schema）
2.谁批准、谁执行？ → harness（代码）
3.工具怎么接入？ → 打包方式（packaging）
4.全公司层面谁控制？ → 网关与管理员
关键洞察：四个归属方会独立地失效。 契约写得再清楚，救不了一个什么都会批准的 harness；harness 再谨慎，也担保不了一个未审计的第三方服务器。
历史纵深：四十年老问题，新 caller（Ch.1）
这一章是全课的思想底座。从 1984 年 Birrell & Nelson 的 RPC、1991 年 CORBA、2000 年 SOAP/REST、2016 年 LSP、2017 年 OpenAPI，到 2023 年 function calling、2024 年 MCP、2025 年各家采纳、2026 年托管 agent loop，管道一直在换包装，底层问题从未解决：
•「调用到底执行了没有？」 1984 年的答案至今成立：失败的调用「要么执行了一次，要么根本没执行；用户无从得知」。超时后盲目重试可能让退款付两次。
•2023 年的真正变化是 caller 变成了模型：它读自然语言描述去「猜」该调哪个工具，可能选错、可能幻觉出不存在的工具（Gorilla 命名了这一失败）、可能被工具输出中的文本误导（OpenAI 发布当天就警告了 prompt injection）。
•MCP（2024.11 开源）借的是现成管道：JSON-RPC 2.0、LSP 式握手、JSON Schema；但借不来答案。协议层面不执行安全；2026-07 版甚至删掉了会话与握手，走向 REST 式无状态（状态改为显式 handle 传回）。
课程给出一个精炼的判断标尺（来自 Yan Wang 的客座讲座）：每个热词都捆绑着一个「持久问题」和它诞生年份的「包装」。 两个检验问题：① 如果模型强 10 倍，这件事还重要吗？② 它到底解决什么问题，我还有这个问题吗？「退款需不需要审批」通过两问（持久）；「工具列表走什么传输协议」通不过第一问（包装）。这是决定学习投入和架构决策的复利式思维。
工具的解剖学与调用全链路（Ch.2–3）
第 2 章把工具拆成三层（课程自己的综合，配自动售货机类比）：
•契约层（按钮标签）：名称、描述、schema，模型唯一能看到的东西
•实现层（机器内部）：代码、凭证、副作用，readOnlyHint: true 可以撒谎，「服务器可以声称只读，然后照样删你的文件」
•知识层（贴在机器上的便条）：什么时候用、按什么顺序、有什么坑，活在描述、CLAUDE.md、skill 里
一个高价值区分：缺能力（capability）加工具，缺知识（knowledge）加描述/instruction/skill。 写出全表扫描 SQL 的 agent 需要的是知识，不是第三个查询工具。另外，工具调用按效果分三类「感知（读环境）、行动（改环境）、计算（纯变换）」类别属于这次调用而非工具名：同一个 SQL 工具，SELECT 是感知，INSERT 是行动。只用计算类工具的系统「可以说不算 agent」。
信任任何工具前的四问：读还是写？跑两次会怎样？用谁的密钥、权限边界多大？契约和结果是谁写的？（后两个问题直指注入与凭证治理。）
第 3 章追踪一次完整的 get_weather 调用，是全课最「工程」的一章：
•工具定义三字段（name/description/input_schema）全部变成模型上下文里的文本，每一轮都按 input token 计费；不管用没用到
•同一个调用在不同模型有四种线上格式（Qwen 2.5 的 <tool_call>、Qwen 3.8 的嵌套标签、Mistral 的专用控制 token、DeepSeek 的 DSML）；自托管必须配对解析器
•harness 分发六步：parse → look up → validate → permission → execute → observe，每步有独立失败模式；校验 ≠ 权限：一个 schema 合法的调用仍可被规则拒绝
•约束解码（constrained decoding，把违反语法的 token 的 logit 压到 −∞）能保证格式，但课程给出清醒的四道门：Valid（格式对）→ Correct（值对）→ Safe（此处此刻允许）→ Done（任务真完成）。约束只保证第一道。MCP-Atlas 的数据佐证：强模型 schema 合规率都超 98%，但最大失败份额是「根本没调工具」（36%），参数错误只有 14.2%；瓶颈在规划与推理，不在格式
•错误信息要写给模型读：具体、可行动，而非 KeyError 堆栈；错误本身是改进工具描述的信号
•动作格式三种：文本、JSON、代码（CodeAct）。代码在组合调用时优势明显（20 个城市一次循环 vs. 20 个结果灌进上下文），代价是失去控制，必须配沙箱
五种打包方式：同一能力，五种交付（Ch.4）
全课的决策核心章。同一个能力可以用五种方式交给 agent：函数、CLI+指令文件、Skill、MCP 服务器、代码执行，各有契约、实现、知识、知晓方式四个落点。
几个要点值得记住：
•Sierra 的案例是全章引子：把 GitHub 官方 MCP 服务器（数百工具）接给 agent 后，agent 浪费时间在工具发现上、响应撑爆上下文；换成模型训练中早已熟悉的 gh CLI + 只读限域 token，问题消失。能力没变，包装变了。
•Skill 不强制任何事：三级渐进披露（元数据 ~100 token 常驻 → 正文按需 → 资源按需），本质是「一张菜谱卡，它不会做菜，也拦不住你忽略它」。SkillsBench 显示策展 skill 平均提升 +16.6 个百分点，但 87 个任务中仍有 13 个被拖累；GPT-5.1 在 τ-bench 上有无 skill 库都是 62.6%；上限由基线能力决定。
•MCP 标准化的是发现、传输和客户端身份，不解决上下文管理和「该不该执行」。它真正的独特价值是凭证代理（credential brokering）：harness 持有一把钥匙给 MCP 服务器，服务器用另一把凭证访问上游；模型两把都看不到，这与 shell 里直接握着 API key 形成鲜明对比。
•注解、注册表、基金会治理都不是安全控制：readOnlyHint 是不可信的自述；注册表只做格式检查和事后下架，「电话簿不做后厨卫生检查」。
•代码执行把中间结果留在沙箱、只回传最终答案（有案例从 150K token 降到 2K），但写操作保持直接调用以保留清晰的授权边界；这是 OpenAI 与 Anthropic 一致的指导。
•判断规则很实用：单 agent 三个小工具 → 本地函数；五个团队跨三个 host、agent 不该持有密钥 → MCP 才对得起它的成本。 默认路径：先 CLI + 指令文件，等分发需要时再加 MCP。
工具越多越糟：先做减法（Ch.5）
工具数量是双向成本：定义每轮都计费（五个常见 MCP 服务器未开口就吃掉 ~55K token），且选择准确率随工具数下降；ToolMenuBench 显示从全量工具 32.1% 升到筛选后 85.7% 的任务成功率。
课程给出按成本从低到高的行动阶梯，这是极好的工程纪律：
1.减：删掉不用的、合并总是一起调的、去掉代码已知的参数（30 个工具可无基础设施地减到 ~18 个）
2.分组：命名空间/前缀，为整组延迟加载做准备
3.按需加载（tool search / defer_loading）：Anthropic 案例，上下文从 77K 降到 8.7K，准确率反升；但检索会 miss，LiveMCPBench 中近半失败源于检索错误
4.让代码搬运中间数据：上下文只随最终答案增长，不随调用次数 × 结果大小增长
两个易被忽视的坑：中途改 tools 数组会击穿整个 prompt cache（缓存层级 tools → system → messages，前端一改、全量重算）；长结果本身就是上下文毒药（context rot），truncate 是钝刀，Cursor 改为写文件 + 按需 tail。
厂商阈值（OpenAI <20、Anthropic 30–50 退化）是指导值而非定律；课程强调用自己的任务集、单一变量、多次重复、按四层失败记录来做自己的阈值实验。
信任边界：全课的安全重心（Ch.6）
开篇案例：一个有邮箱权限的 agent 开始删除全部邮件，用户打字「别这么做」，它继续删，对话指令只是文字，杀掉进程才是代码。
信任地图上五个角色（用户 → host/harness → 模型 → 工具服务器 → 上游服务），只有 harness 看到每次调用且运行你控制的代码。三条铁律：
1.右侧内容（描述、结果）是数据，不是指令。 工具输出可以影响模型说什么，绝不能决定什么代码被执行。Simon Willison 的 lethal trifecta：私有数据 + 不可信内容 + 对外通信通道，三者齐备攻击者必胜。2025 年三个真实案例中招的方式各不相同（GitHub issue 注入经官方 MCP 泄私库、Supabase 工单注入读生产表），而有效的修复全是结构性的：GitHub 每会话限一个仓库、只读 token、dev/prod 数据库自动分离（Replit 事故的整改）。
2.确认对话框会失败：参数被折叠看不见（Cursor 事件中对话框只显示工具名，看不见 ~/.ssh/id_rsa 被塞进参数）、习惯性点「Always Allow」、设置直接绕过。对话框之下必须有结构限制。
3.凭证治理：混淆代理（confused deputy）问题，服务器只检查「我有没有权限」，不检查「触发的人有没有」。原则：交互式工作以用户身份运行（不大于其权限），定时/共享工作以最小权限 service account 运行；两种情况下密钥都不进模型。 MCP 规则要求服务器不得透传客户端 token 到上游。
供应链一章（postmark-mcp 恶意 BCC、MCP Inspector CVE 9.4）提醒：有些攻击不需要骗模型；服务器本身就是攻击，参数检查永远抓不到服务器代码内部的一行 diff。对策是普通卫生：锁定已审计版本、hash 钉住工具描述、localhost 绑定。
组织规模与度量（Ch.7–8）
第 7 章把视角拉到公司层面：没有网关时，4 个 agent × 4 个服务 = 16 条连接、16 套日志；网关把身份、权限、审计收拢到一点（Sierra：89% 员工、45 个服务）。两个身份原则延续第 6 章；MCP 企业托管授权解决了离职即时吊销的问题。注册表只列不审；审计责任永远在公司自己。
第 8 章是方法论核心，几个概念密度极高：
•四层失败框架（CMU）：Selection（调没调对工具）→ Arguments（参数对不对）→ Trajectory（顺序对不对）→ Task（目标达没达成）。层次之间互相遮蔽；没调用就没有参数可评，一个总分看不出断在哪层。MCP-Atlas 数据：约四成失败是「该调没调」，只有约七分之一是参数错。
•pass@k vs pass^k：单次成功率 0.9 的 agent，pass^8 ≈ 0.17；能力（能不能做到）与可靠性（无人值守每天全对）是两回事。HAL 的发现：能力提升并没有同步改善可靠性；重复运行间漂移的正是 trajectory（「知道做什么，不确定什么时候做」）。
•Setup 是结果的一部分：同一 Claude 模型、同一 BFCL 快照，原生 function calling 77.47 分（第 1），prompt 方式 33.47 分（第 57）；差 40 多分。任何数字必须连同模型/版本、调用方式、harness、格式、评分器、日期一起记录。
•任务完成 ≠ 安全：两次都正确退款，其中一次多读了别的客户记录。HarnessAudit：任务完成率与安全合规呈负相关。结论：日志要记录每次调用触碰了什么而非只记录返回了什么。
•最后落到做实验而非刷分数：一次一个问题、固定任务集、单变量、多次试验、按层和来源记录失败、读失败 transcript（Opus 4.5 在 τ2-bench 上「利用政策漏洞」找到了对用户更好的解却被判错；评分器也会错）。
五个判断与五个开放问题（Ch.9–10）
第 9 章收拢全课为五个决策，每个都用「模型强 10 倍还重要吗」检验：
判断10x 检验结果给模型哪些动作仍然重要，更好的模型缩小不了爆炸半径一次让模型看多少半对半，选择力会提升，但 token 计费、cache 失效是系统成本谁决定这一步执行完全重要；更聪明的模型无法撤销一次写操作谁的话能左右动作完全重要，模型读的是一条 token 流，攻击者只需成功一次选哪种打包大部分是包装，但切换成本真实存在
模式很清晰：两个「完全重要」的判断（3、4）正是靠结构（代码闸门、单仓库会话）决胜的地方，把有限时间花在那里。
第 10 章诚实地划出证据边界，五个没有答案的问题：超时的写调用到底跑没跑（至今无协议级方案，idempotentHint 是不可查的自述）；已批准的工具描述可被「rug pull」掉包（hash 钉住只能发现变了，不能判断新的有没有毒）；托管 loop 的默认权限策略成为你的行为（auto 评估器的错误率未公开）；skill 在下一个模型上还有没有效（无跨代际追踪研究）；agent 应不应该是自己的安全主体（目前所有方案都是「借用」身份，个人 token、service account 或共享凭证，审计日志无法区分「agent 代你做的」和「你自己做的」）。
总体感受
这一讲的质量在同类课程中相当突出，有三个鲜明特点：
1.历史维度带来的判断力。 用 1984 年 RPC 论文锚定「did it run」，用 CORBA/UDDI 的失败预演 MCP 注册表的局限，用 REST 无状态解释 MCP 2026 的转向，学生获得的不是「怎么接 MCP」，是「哪些东西值得深学」的复利判断。
2.证据纪律罕见地严格。 每个数字都标注来源与局限（厂商自报无样本量、基准随时间漂移、平均值掩盖 13/87 的负增益），并反复示范如何反驳「strict mode 让工具调用可靠」这类流行说法。pass@k/pass^k、四层失败框架、「setup 是结果的一部分」都是可直接落地的工程方法。
3.一以贯之的世界观：提示是便条，代码是锁。 从开篇「模型写订单、程序做菜」到结篇「两个完全重要的判断都由结构决定」，所有安全结论都收敛于一点，把执行、凭证、审批放进模型动不了的地方。
一句话概括这一讲的核心：工具调用是四十年老问题换上了新 caller；模型只负责提议，一切值得信任的东西「执行、权限、密钥、重试安全」都住在模型之外，那才是工程发生的地方。