评估编程智能体（coding agents）的工程团队通常从错误的问题开始。他们想知道智能体的自主性有多高。它能接管多少工作流？它能否在不打扰任何人的情况下编写规范、编辑代码库并推送到生产环境？演示视频让这种痴迷变得理所当然。你会看到一个流畅的工作流，只需一个提示词就能触发一系列编辑和部署，于是本能地想在自己的组织内部追求同样的能力。但华丽的外表并非好的设计原则。更重要的问题则远没有那么令人兴奋：是谁赋予了它权限？它实际上能触及哪些系统？当它不可避免地出错时会发生什么？

自主性陷阱

令人兴奋的自主性是一个陷阱。它训练我们去赞美那些能够生成规范、修改代码库并部署代码，同时还淡定地声称任务已完成的机器人。这不是工程，这是在拥有 Shell 访问权限的情况下玩“信任背摔”。工作本身变得几乎过于容易产出了。任何模型都可以在几秒钟内大量产出代码、文档或架构方案。但软件开发的真实成本从来不是打字速度，而始终是验证、评审，以及做出“是的，这是正确的且可以安全发布”这一谨慎决策的过程。生成的工作是廉价的，审批才是昂贵的。那些能够理清如何干净、一致地处理审批流程的公司，才是真正能够交付可靠系统的公司。

为什么自我评审会失败

风险会以可预测的模式出现。模型起草了一个计划，然后评估该计划是否可行。智能体编辑了你的代码库，并向你解释为什么它的更改是安全的。工具执行了一个命令，并且是“先斩后奏”而非“先请示后行动”。这些都代表了同一个核心失败。如果一个智能体生成了规范，那么在它成为事实之前，必须由该智能体之外的某个环节进行签核。如果一个智能体修改了代码，必须由一个独立的流程来检查 diff。让生成器充当自己的验证器并不是捷径，而是伪装成便利性的结构性缺陷。

提示词不是权限系统

你无法通过巧妙的措辞来确保智能体的安全。告诉模型要小心或者在删除某些内容前先询问，并不能建立边界。提示词（Prompts）不是权限系统。在让智能体接触生产环境之前，你需要对其能力进行一次诚实的盘点。它能读取整个代码库吗？它能执行 Shell 命令吗？它能打开浏览器吗？它能将客户数据拉入其上下文窗口吗？大多数团队并不了解完整的答案。他们假设工具被限制在沙盒中，而实际上它拥有对关键路径的写入权限。先绘制其接触范围，然后再筑起围墙。

构建分层控制系统

一旦你了解了智能体能做什么，就要设计一个将风险与摩擦力（friction）相匹配的控制系统。低风险操作，如更新内部文档或格式化一致的代码，可以自动运行。中风险操作，如重构模块或添加新的依赖项，应该设置一个检查点，由人工或经过验证的测试套件来确认该操作。高风险操作，如部署到生产环境、修改基础设施或访问敏感数据，需要一个未参与生成的独立审批人。每一个动作都必须留下审计追踪。你应该能够精确地回溯读取了哪些文件、调用了哪些工具以及做出了哪些决策。智能体驱动的开发并不意味着可以跳过评审。枯燥的摩擦力是一种特性。当情况开始偏离轨道时，一个适当的审批关口就像断路器一样发挥作用。

使边界与风险相匹配

根据实际危险程度来校准你的边界。将每一次 Markdown 格式微调都变成一场合规仪式，会让你的团队陷入停滞。但仅仅因为智能体看起来很有信心，就将高风险操作视为无害，同样是愚蠢的。目标是比例适度的控制，而不是戏剧化的限制。

保持产出物的小型化与可观测性

The most useful agent systems do not try to wow you with massive autonomous runs. They produce small, reviewable artifacts. A tight plan. A focused diff. A readable log. Giant autonomous executions are nightmares to debug. When something breaks after a fifty-file agent session, you have to untangle intent, execution, and side effects all at once. Keep the blast radius small. Insist on knowing which files the agent read and which tools it called. Observable systems are maintainable systems. Black-box autonomy is just technical debt with better marketing.

Six Questions Before You Grant Access

Before you hand an agent any real responsibility, pressure-test your setup with six hard questions.

  • What capabilities does the system actually have?
  • Which actions are denied by default, blocked at the infrastructure level rather than discouraged by a polite sentence in the system prompt?
  • Which actions require explicit approval?
  • Which artifacts get frozen before the agent consumes them, so it cannot silently manipulate its own inputs?
  • Which validator, entirely separate from the generator, judges the final output?
  • Which log proves, without ambiguity, what actually happened?

This is basic engineering hygiene. Separate the generator from the validator. Keep human authority at the boundary.

The Real Test

There