可靠 Agent 的四个工程门槛

Agent 能调用工具并不等于它可以安全地进入真实系统。越接近生产环境，越需要把“聪明”转换成可控制、可观察、可恢复的工程行为。

一、权限边界必须先于执行

默认允许一切，再依靠模型谨慎判断，是不可靠的设计。更合理的做法是按影响分级：

• 读取文件、搜索和本地构建可以自动执行；
• 修改配置、安装依赖需要明确记录；
• 生产切流量、数据删除、权限与安全策略修改必须人工确认。

权限应尽量绑定到具体资源和时间窗口，而不是给出永久、全局的能力。

二、执行过程必须可观察

用户应当知道 Agent 正在做什么、为什么做，以及下一步需要什么条件。

一个可观察的执行过程至少包含：

1. 当前目标与约束；
2. 已读取的事实来源；
3. 即将发生的变更；
4. 命令或工具的实际结果；
5. 失败后停在什么状态。

这不是为了输出更多日志，而是为了让人工可以在关键节点接管。

三、完成必须由独立证据证明

“代码已经写好”不是完成，“服务应该正常”也不是证据。Agent 应根据任务选择可重复的验证：

• 变更行为对应的单元测试；
• 类型检查、Lint 或构建；
• 配置语法检查；
• 外部协议级验收；
• 文件内容、监听端口和服务状态的交叉核对。

验证最好与实现步骤分离，避免同一个错误假设同时污染实现和检查。

四、回滚必须和变更一起设计

先修改、失败后再想如何恢复，会把小问题放大。安全执行通常遵循：

1. 修改前备份并记录路径；
2. 先增加新路径，验证后再删除旧路径；
3. 使用临时文件和原子替换；
4. 变更脚本设置失败处理；
5. 回滚后再次验证服务，而不是只复制文件。

一个实用判断

如果 Agent 不能清楚回答下面四个问题，就不应直接执行高影响操作：

• 我将修改什么？
• 我如何知道修改成功？
• 失败时当前会话是否仍可用？
• 我用什么具体步骤恢复？

可靠性不是限制 Agent 能力，而是让能力可以进入真正重要的系统。