Steer by Intent, Monitor by Exception

以意图为导向，以异常为准绳

The most expensive thing you can do with an AI agent is watch it. Not audit it. Not review its output. Watch it — step by step, approval by approval, second-guessing every action before it takes the next one. And yet that is precisely how most engineering teams are deploying AI agents in 2026: on a leash so short the agent cannot take three steps without a human tapping it on the shoulder. 在使用 AI Agent 时，成本最高的操作就是“盯着它看”。不是审计它，也不是审查它的输出，而是盯着它看——一步一停，一次审批接一次审批，在它执行下一步之前对每一个动作都进行质疑。然而，这正是 2026 年大多数工程团队部署 AI Agent 的方式：给它套上一根极短的绳子，导致它每走三步就得停下来等人类拍拍它的肩膀。

I understand why. The models hallucinate. The stakes are real. Nobody wants to be the engineering manager who let an AI agent push a bad migration to production at 2am. So we wrap the agents in confirmation dialogs, require human sign-off at every branch point, and celebrate our careful governance. What we have actually built is an automation system that requires more human attention than the manual process it replaced. 我理解其中的原因。模型会产生幻觉，风险也是真实存在的。没人想成为那个在凌晨两点让 AI Agent 推送了错误数据库迁移脚本的工程经理。因此，我们给 Agent 套上了确认对话框，要求在每个分支点都必须有人工签字，并为这种“谨慎的治理”沾沾自喜。但实际上，我们构建的是一套比它所取代的手动流程更需要人类关注的自动化系统。

The better answer is not more control at the action level. It is better design at the intent level. Steer by intent, monitor by exception. Tell the agent clearly what outcome you need, what it must never do, and what constitutes a result worth stopping for. Then let it work. Watch the outcomes, not the steps. 更好的解决方案不是在操作层面进行更多控制，而是在意图层面进行更好的设计。以意图为导向，以异常为准绳。明确告诉 Agent 你需要什么结果、它绝对不能做什么，以及什么样的情况值得它停下来。然后，放手让它工作。关注结果，而不是过程。

We have built automation systems that require more human attention than the manual process they replaced. That is not a governance success. That is a design failure. 我们构建的自动化系统比它们所取代的手动流程需要更多的人类关注。这不是治理上的成功，而是设计上的失败。

Why we got here

我们为何陷入这种境地

The model for human-AI collaboration that most teams are using today was inherited from the model for junior developer supervision. You review every pull request. You approve every deployment. You sign off on every schema change. That model exists because junior developers are learning, because their mental models are incomplete, because their judgment has not yet been earned. 大多数团队目前使用的人机协作模型，是从初级开发人员的监督模式中继承而来的。你审查每一个 Pull Request，批准每一次部署，确认每一次架构变更。这种模式之所以存在，是因为初级开发人员还在学习，他们的思维模型尚不完整，且尚未建立起足够的判断力。

Applied to AI agents, it assumes the same thing: the agent is a novice that needs supervision. But an AI agent is not a junior developer. It does not have an incomplete mental model of the codebase that will improve with mentorship. It has exactly the mental model you gave it via its context, its tools, and its instructions — and it will use that model consistently and at a speed no human reviewer can match. 将其应用于 AI Agent 时，我们默认了同样的假设：Agent 是一个需要监督的新手。但 AI Agent 并非初级开发人员。它不存在那种可以通过指导来完善的“不完整代码库思维模型”。它拥有的思维模型完全取决于你通过上下文、工具和指令赋予它的内容——而且它会以人类审查者无法企及的速度，始终如一地执行该模型。

The bottleneck in most AI-agent workflows today is not the agent. It is the queue of human approvals the agent must wait in. More importantly, action-level oversight creates a false sense of security. When you approve every individual step, you are not ensuring the outcome is correct. You are ensuring each step looked reasonable to someone who reviewed it for thirty seconds. Those are not the same thing. A sequence of individually reasonable steps can produce a collectively disastrous result, and the approval chain will have signed off on every one of them. 目前大多数 AI Agent 工作流的瓶颈不在于 Agent 本身，而在于它必须等待的人工审批队列。更重要的是，操作层面的监督会产生一种虚假的安全感。当你批准每一个单独的步骤时，你并不能确保最终结果是正确的。你只是确保了每一个步骤在某人匆匆扫视三十秒后看起来“还算合理”。这两者完全不同。一系列单独看起来合理的步骤，可能会产生灾难性的整体结果，而审批链条却对其中的每一步都签了字。

What intent-steering actually means

什么是真正的“意图导向”

Steering by intent means front-loading the governance. Before the agent starts, you define three things precisely. First, the outcome: not a list of tasks, but a measurable definition of done. Not ‘refactor the authentication module’ but ‘the authentication module passes all existing tests, introduces no new dependencies, and reduces cyclomatic complexity by at least fifteen percent.’ 以意图为导向意味着将治理工作前置。在 Agent 开始工作之前，你需要精确定义三件事。第一，结果：不是任务清单，而是可衡量的“完成定义”。不是“重构认证模块”，而是“认证模块通过所有现有测试，不引入新的依赖项，并将圈复杂度降低至少 15%”。

Second, the constraints: the things the agent must never do regardless of how reasonable they seem in context. No changes to production database schemas without a migration script. No external API calls to services not already in the approved ConnectionTwin registry. No file deletions without creating a recovery snapshot first. 第二，约束：无论在上下文中看起来多么合理，Agent 都绝对不能做的事情。例如：没有迁移脚本不得更改生产数据库架构；不得调用未在已批准的 ConnectionTwin 注册表中的外部 API；不得在未创建恢复快照的情况下删除文件。

Third, the escalation threshold: the specific conditions under which the agent stops and waits for a human. Not ‘when uncertain’ — that is too vague and the agent will never stop. Specific conditions: if test coverage drops below eighty percent, stop. If a dependency with a known CVE is introduced, stop. If the refactor touches more than twelve files, stop and summarise before proceeding. 第三，升级阈值：Agent 停止并等待人工介入的具体条件。不是“当不确定时”——这太模糊了，Agent 永远不会停下来。必须是具体条件：如果测试覆盖率低于 80%，停止；如果引入了带有已知 CVE 的依赖项，停止；如果重构涉及超过 12 个文件，停止并总结后再继续。

Everything else is the agent’s to decide. How it structures the refactor. Which functions it rewrites first. What intermediate states it moves through. You do not care about those decisions. You care about the outcome. Stop trying to approve the route and start inspecting the destination. 除此之外的一切都由 Agent 自行决定。它如何组织重构、先重写哪些函数、经历哪些中间状态，你都不必关心。你关心的是结果。停止试图批准路线，开始检查目的地。

What exception monitoring actually means

什么是真正的“异常监控”

Monitoring by exception means you are not reading transcripts of what the agent did. You are watching a dashboard of outcomes against the criteria you defined upfront. Test coverage: did it hold? Security surface: did it grow? Performance benchmarks: did they move? Constraints: were any violated? 以异常为准绳的监控意味着你不需要阅读 Agent 执行过程的记录。你只需要观察一个仪表盘，对比你预先定义的标准。测试覆盖率是否保持？安全面是否扩大？性能基准是否波动？约束条件是否被违反？

If all four are green, you review the agent’s summary and ship. If any are red, you get paged. Not because the agent failed — it did exactly what you told it to do, which was to stop when these conditions were met. It stopped. Now a human makes the call. 如果这四项都是绿色的，你只需查看 Agent 的总结并发布即可。如果任何一项变红，你就会收到警报。这并不是因为 Agent 失败了——它完全按照你的要求执行了任务，即在满足这些条件时停止。它停下来了，现在由人类来做决定。

This is how every well-designed automated system in software engineering already works. CI/CD pipelines do not ask a human to approve each compilation unit. They run the full suite and alert on failure. Observability platforms do not page you for every log entry. They model baseline behavior and alert on deviation. We designed those systems with a clear principle: trust the process, intervene on exception. We need to apply the same principle to AI agents, and we have been bizarrely reluctant to do so. 软件工程中每一个设计良好的自动化系统都是这样工作的。CI/CD 流水线不会要求人类批准每一个编译单元，它们运行完整的测试套件并在失败时发出警报。可观测性平台不会为每一条日志都向你发送警报，它们会对基准行为建模，并在出现偏差时发出警报。我们设计这些系统时遵循一个明确的原则：信任流程，异常介入。我们需要将同样的原则应用于 AI Agent，但我们对此却表现出一种奇怪的抗拒。

The reluctance comes, I think, from a category error. We are treating AI agents as autonomous decision-makers whose judgment needs checking, rather than as deterministic-enough process executors whose outcomes need verifying. Once you make that shift, the governance model changes entirely. You are not supervising a person. You are operating a system. Systems get monitored, not managed. 我认为这种抗拒源于一种分类错误。我们将 AI Agent 视为需要检查其判断力的“自主决策者”，而不是需要验证其结果的“足够确定性的流程执行者”。一旦你完成了这种转变，治理模型就会彻底改变。你不是在监督一个人，而是在操作一个系统。系统需要的是监控，而不是管理。

The objection worth taking seriously

值得认真对待的反对意见

The real objection to this approach is not that it is wrong in principle. It is that defining precise intent is hard. Writing a genuinely measurable outcome definition, a complete constraints list, and a well-calibrated escalation threshold takes time and expertise. It requires the engineering mana… 对这种方法真正的反对意见不在于原则错误，而在于定义精确的意图非常困难。编写真正可衡量的结果定义、完整的约束列表以及校准良好的升级阈值，需要时间和专业知识。这需要工程管理……