给 Agent 做工具白名单：把能力边界写在配置里，而不是写在提示词里

用提示词约束 Agent不要做某件事是一种很脆弱的做法。模型可能理解偏也可能在上下文变长之后忽略掉那句约束还可能被页面上的内容影响判断。更稳的方式是把边界写在工具层它能调用的工具本身就是它的能力上限。先按风险分级只读类工具风险最低检索、解析、查询、读文档这些操作最坏的结果是拿到错误信息不会改变任何状态。写入类工具次之创建文件、提交内容、修改配置。这类操作会留下痕迹做错了要收拾。执行类工具风险最高跑代码、装依赖、访问外部网络。它的影响面不只是结果错还包括资源和副作用。分级之后白名单问题就变成了一个更清楚的问题这条流程最多允许到哪一级。再按流程配白名单不要给每个 Agent 一份全量工具清单而是按任务给它需要的子集做资料整理的 Agent 不需要执行能力做数据处理的 Agent 不需要发布能力做验收的 Agent 不需要写入能力。工具少一点失败面就小一点模型的选择困难也小一点。实践里最常见的问题不是工具不够而是工具太多导致模型挑了不合适的那个。在入口处做隔离把不同用途的调用拆到不同的密钥上是成本最低的隔离方式泄露一个不会连带影响其他流程出问题时从调用记录就能直接看出来源额度也能分开观察。隔离的粒度不必太细按用途拆就够了检索用一个、解析用一个、执行用一个。粒度太细会让配置变成负担反而没人愿意维护。明确越权时的正确行为当 Agent 需要一个它没有的工具时正确行为是停下来报告缺什么而不是去找替代路径把事情做完。这一点必须在流程说明里明确写出来否则模型的默认倾向是绕路用能调用的工具拼一个近似效果看起来完成了实际上偏离了要求。同时也要让停下来变得有信息量报告缺的是哪类能力、原本想用它做什么、有没有只读的替代方案。这样的报告能直接变成下一次白名单调整的依据。定期复核防止边界漂移白名单会随流程漂移慢慢变松临时加过一个工具之后就没人删了某次调试放宽过权限也忘了收回去。按月看一遍调用记录问三个问题这个工具最近有没有被真正用到它的调用结果有没有进入最终产出如果去掉它流程会断在哪一步三个问题答不上来的权限就应该先收掉。为什么这样更省事用提示词写边界本质上是赌模型每次都听话用工具白名单写边界是让做不到变成结构上的事实。后者不需要模型配合也不依赖上下文长度更不需要每次都在提示里重复强调。对长期运行的 Agent 来说稳定性来自结构而不是来自纪律。一个具体的配置示例思路把同一条流程需要的工具列成一张表能力名称、调用用途、是否只读、失败时是否可重试。表格填完之后再回头看有哪些行其实是重复的、哪些行从来没有被触发过。这张表的好处是可评审别人能看懂你为什么给它这些能力也能指出多给的部分。相比之下当时为了图方便全给了是无法评审的。