AI自主公司的控制平面：三条泳道让智能体可控

“自主公司”听起来像是一个模型选择题——选对模型就能自动运转。但实践中的关键并非模型本身，而是一套控制平面（control plane）的设计。本文基于一篇引发讨论的技术博客，拆解一种为小型服务公司设计的控制平面：把每个任务分入工作流、智能体、人工三条泳道，并在代码层面强制执行边界。

为什么控制平面比模型选型更重要

原文用一个做线索接待（lead intake）的小型服务公司作为示意场景（作者明确说明这是示例，不是客户案例，也没有结果数据可分享）。核心观点是：所谓“自主公司”，真正决定成败的是任务如何被路由、工具权限如何被限制、哪些动作必须由人拍板——这些都不应该写在提示词里，而应该写进代码。

这一判断与业界主流观点形成交叉印证。Anthropic 的指南指出，编码化的工作流在定义明确的任务上提供可预测性，而智能体则带来更高成本和复合错误，因此应在带护栏的沙盒中测试。Salesforce 提出的“混合推理”（hybrid reasoning）同样主张把确定性逻辑与自适应 AI 结合起来。三条泳道正是实现这种混合的一种极简方式。

控制平面（control plane） 一词借自网络与云计算领域，原指负责系统配置、路由决策和策略下发的核心组件，与承载实际数据流的数据平面（data plane）相对。在 AI 智能体语境中，控制平面指的是在模型之外、用确定性代码实现的调度层：它决定任务流向哪条处理路径、允许调用哪些工具、何时必须由人介入。将控制逻辑从提示词中剥离出来，意味着这些规则不再依赖模型的概率性服从，而是像基础设施配置一样可版本化、可审计、可测试。这也是原文强调「写入代码而非提示词」的技术含义——控制平面对应的是策略层，而非智能本身。

三条泳道：工作流、智能体、人工

原文用枚举类型定义了三种任务归属：

• WORKFLOW（工作流）：固定步骤，模型不做决策。例如捕获线索、发送模板邮件。
• AGENT（智能体）：模型在限定范围内选择步骤。例如读取 CRM 并起草回复。
• HUMAN（人工）：由人做决定。例如报价定价。

每个任务被建模为一个数据结构，携带名称、所属泳道、可调用工具列表，以及是否需要审批的标记。示意代码中，capture_lead 和 send_reminder 属于工作流泳道，只允许触碰 crm.create 和 email.send_template；draft_reply 属于智能体泳道，可读写 CRM 并起草邮件；quote_price 则完全交给人工，不开放任何工具。

这种划分的价值在于把“谁能做什么”变成静态可审计的配置，而不是依赖模型在运行时自我约束。

工作流（workflow）与智能体（agent） 的关键差异在于决策的确定性。工作流是预定义步骤的编排，每一步的输入输出和调用工具都在设计时固定，模型不参与分支选择，因此行为可预测、成本可控。智能体则让模型在运行时根据上下文选择下一步动作，灵活性更高，但会引入复合错误——前一步的偏差可能被后续步骤放大，且 token 消耗随步骤增加而上升。将任务归入哪条泳道，本质上是在确定性与灵活性之间做权衡。原文的枚举设计把这一权衡显式化，使每个任务的自主程度成为可审查的配置项，而非隐含在提示词的模糊描述中。

路由器：把边界写进代码而非提示词

控制平面的核心是一个路由函数。它在任务开始时记录日志，然后按顺序判断：如果任务属于人工泳道或标记了需要审批，直接进入人工队列；如果属于工作流泳道，执行固定步骤；否则交给智能体，并把任务声明的工具列表作为 allowed_tools 传入。

原文强调，有三样东西存在于路由器而非提示词中：任务可以触碰哪些工具、哪些任务需要审批、哪些动作会被记录。这是整个设计的关键区别——提示词可以被模型“说服”或忽略，而代码中的分支不会。

allowed_tools（允许工具列表） 是一种能力白名单机制：任务在数据结构中声明自己可以调用哪些工具，路由器在执行前将该列表传入，智能体只能在此范围内行动。这与安全领域的最小权限原则（principle of least privilege） 一脉相承——每个任务只获得完成其职责所必需的最小工具集，从而把越权操作的可能性压缩到配置层面。相比在提示词中写「不要发送邮件」之类的软约束，白名单是硬性拦截：即使模型被诱导或产生幻觉，未列入列表的工具调用也无法发生。这种机制让权限边界独立于模型行为，成为可静态检查的安全属性。

事故处理：暂停开关与责任人

控制平面还包含一个最小化的事故处理机制：维护一个被暂停任务的集合，提供 pause 函数，把任务名加入集合并记录是谁执行了暂停。路由函数在开始时检查该集合，被暂停的任务不再自动执行。

原文提出两条硬性要求：暂停必须有人负责，日志必须记录是谁按下了开关。这看似简单，却是很多“自主”系统缺失的一环——系统出问题时，没人说得清该找谁。

应该先写进代码的三条红线

原文给出了三条应优先编码的红线：

1. 钱、合同和客户承诺永远交给真人。 这类动作的错误的代价不可逆，不适合交给概率性系统。
2. 每个智能体动作都有包含输入输出的日志条目。 可追溯性是事后审计和事故复盘的前提。
3. 每个任务都有具名负责人和一个关闭开关。 没有归属的任务不应该存在。

这三条与 Anthropic 关于沙盒和护栏的建议方向一致，也与 Microsoft 2025 工作趋势指数中“人类设定方向、按需介入”的描述相呼应——控制平面正是让“按需介入”从口号变成可执行机制的方式。

这不是什么

原文作者明确划清了边界：这套设计不能证明一家公司可以自行运转。它解决的是控制问题，不是能力问题。人类仍然负责设定方向，并在需要时介入；控制平面的作用是让这种介入有具体的落点——一个暂停按钮、一条审批队列、一份带责任人的日志。

对于正在把智能体引入业务流程的团队来说，这个框架的借鉴意义在于：先设计泳道和红线，再谈自主程度。模型会换，控制平面的结构可以留下来。

（原文作者为 GrowEasy.ai 创始人 Tej Pandya。）