企业官网建设流程全解析

用提示词约束 Agent"不要做某件事"，是一种很脆弱的做法。模型可能理解偏，也可能在上下文变长之后忽略掉那句约束，还可能被页面上的内容影响判断。更稳的方式是把边界写在工具层：它能调用的工具，本身就是它的能力上限。

先按风险分级

只读类工具风险最低：检索、解析、查询、读文档，这些操作最坏的结果是拿到错误信息，不会改变任何状态。

写入类工具次之：创建文件、提交内容、修改配置。这类操作会留下痕迹，做错了要收拾。

执行类工具风险最高：跑代码、装依赖、访问外部网络。它的影响面不只是"结果错"，还包括资源和副作用。

分级之后，白名单问题就变成了一个更清楚的问题：这条流程最多允许到哪一级。

再按流程配白名单

不要给每个 Agent 一份全量工具清单，而是按任务给它需要的子集：做资料整理的 Agent 不需要执行能力，做数据处理的 Agent 不需要发布能力，做验收的 Agent 不需要写入能力。

工具少一点，失败面就小一点，模型的选择困难也小一点。实践里最常见的问题不是工具不够，而是工具太多导致模型挑了不合适的那个。

在入口处做隔离

把不同用途的调用拆到不同的密钥上，是成本最低的隔离方式：泄露一个不会连带影响其他流程，出问题时从调用记录就能直接看出来源，额度也能分开观察。

隔离的粒度不必太细，按"用途"拆就够了：检索用一个、解析用一个、执行用一个。粒度太细会让配置变成负担，反而没人愿意维护。

明确"越权时的正确行为"

当 Agent 需要一个它没有的工具时，正确行为是停下来报告缺什么，而不是去找替代路径把事情做完。这一点必须在流程说明里明确写出来，否则模型的默认倾向是绕路：用能调用的工具拼一个近似效果，看起来完成了，实际上偏离了要求。

同时也要让"停下来"变得有信息量：报告缺的是哪类能力、原本想用它做什么、有没有只读的替代方案。这样的报告能直接变成下一次白名单调整的依据。

定期复核，防止边界漂移

白名单会随流程漂移慢慢变松：临时加过一个工具，之后就没人删了；某次调试放宽过权限，也忘了收回去。

按月看一遍调用记录，问三个问题：这个工具最近有没有被真正用到？它的调用结果有没有进入最终产出？如果去掉它，流程会断在哪一步？三个问题答不上来的权限，就应该先收掉。

为什么这样更省事

用提示词写边界，本质上是赌模型每次都听话；用工具白名单写边界，是让"做不到"变成结构上的事实。后者不需要模型配合，也不依赖上下文长度，更不需要每次都在提示里重复强调。

对长期运行的 Agent 来说，稳定性来自结构，而不是来自纪律。

一个具体的配置示例思路

把同一条流程需要的工具列成一张表：能力名称、调用用途、是否只读、失败时是否可重试。表格填完之后，再回头看有哪些行其实是重复的、哪些行从来没有被触发过。

这张表的好处是可评审：别人能看懂你为什么给它这些能力，也能指出多给的部分。相比之下，"当时为了图方便全给了"是无法评审的。