先划边界，再给 Agent 工具

给 Agent 增加浏览器、代码仓库、邮件或数据库工具很容易。困难的是确保它只在正确的时间，以正确的权限完成正确的动作。

工具越多，不确定性越大。设计顺序应该从边界开始，而不是从工具清单开始。

职责要同时写正面和反面

“负责客户运营”过于宽泛。更可执行的描述是：

负责：整理每日客户反馈，归类问题并生成处理建议。
不负责：直接承诺退款、修改合同、对外发送未经审核的回复。

反面边界可以阻止 Agent 把“帮助推进”理解成“代替负责人决策”。

把权限拆成三个层级

读取

允许获取完成任务所需的信息，但要限制数据范围。读取权限仍然可能暴露个人信息、密钥和内部材料。

建议

Agent 可以生成方案、草稿和变更预览，但不改变外部状态。新流程应优先从这一层开始。

执行

只有动作可恢复、目标明确并且验收充分时，才开放写入。付款、删除、发布和对外发送等高影响动作应保留人工确认。

写出明确的停止条件

以下情况应该停止并请求人工处理：

• 输入之间存在冲突；
• 缺少会改变结果的业务选择；
• 需要扩大数据访问范围；
• 即将执行不可恢复的动作；
• 连续尝试后仍无法验证结果。

停止不是失败。一个知道何时停下来的 Agent，比一个永远“继续尝试”的 Agent 更适合进入真实业务。

用真实交付物验收

不要只测 Agent 是否给出了回答。应检查它能否在真实输入中保持权限边界、输出可用结果，并在异常条件下正确停止。

先把边界跑通，再逐步增加工具。这样得到的是可控能力，而不是功能数量。