Harness、Loop、Graph 之后，Agent 工程需要一层控制平面

讨论 Agent 工程时，我习惯把底层拆成 Harness、Loop 和 Graph。Harness 提供模型、工具、权限与运行环境；Loop 负责观察、行动、反馈和终止；Graph 表达步骤、依赖、并发与分支。

这三层能解释单个 Agent 如何完成任务，却解释不了规模化之后的共同问题：几十个 Agent 谁优先、谁能访问生产、预算如何分配、相同失败为何重复发生，以及团队如何统一暂停。

控制平面通过把运行与治理分离来发挥作用：业务 Agent 只声明任务、所需能力和风险级别，平台再解析身份，分配隔离环境与预算，选择模型和工具，并把审批、追踪、重试策略注入执行。这样同一条组织规则无需散落在每个 Graph 节点，也能在不中断业务逻辑的情况下统一升级。版本化策略还能让组织解释同类任务为何在不同时间得到不同处置。

控制平面正是缺失的一层。它不直接完成业务任务，而是集中管理身份、策略、配额、版本、路由、审批、观测与生命周期，把运行决策从每个 Agent 的提示词和应用代码中抽离。

集中治理并不天然更安全。控制平面一旦错误配置，影响会从单个 Agent 扩散到全部任务；过度抽象还可能抹平业务差异，让团队为了适配统一策略而绕开平台。若它只收集海量轨迹却没有明确事件语义，观测数据也会成为昂贵噪音。最大的风险，是把新的单点权力误认为新的确定性。因此控制平面自身也必须分权、审计，并具备安全回退路径。

OpenAI Agents SDK 提供 handoff、guardrail 和 tracing，LangGraph 强调持久化执行，Temporal 提供可恢复工作流。这些能力正在汇聚，但控制平面不是换一个框架，而是把跨框架规则变成组织级契约。

第一项契约是身份。每次执行都应知道代表哪个用户、使用什么服务身份、继承哪些权限，并把子任务的授权范围继续缩小。没有身份链，审计日志只会记录“某个模型调用了某个工具”。

落地时可先从跨应用重复出现的约束开始，而非建设大而全的平台：统一执行身份、任务预算、外部动作审批和终止原因，再为这些事件建立可查询的审计记录。评价标准应包括策略是否真正阻止越权、任务能否从故障恢复、不同框架能否产生一致语义，以及规则变更能否通过影子运行验证影响。先证明最小治理闭环有效，再扩展到模型路由和全局调度。

第二项契约是预算和终止。token、浏览器时间、外部 API、人工审批和失败重试都是真实成本。控制平面要能设定任务级上限、检测无效循环，并在价值继续下降时停止。

第三项契约是可观测性。团队需要跨模型、跨工具比较成功率、延迟、成本和错误类型，而不是只看一段漂亮轨迹。OpenTelemetry 式的统一语义，最终可能比任何一家 Agent 框架的专用面板更重要。

控制平面的深层价值，是把 Agent 从一次性脚本变成组织可以管理的劳动力。模型和编排框架会更换，但谁可以代表谁、资源如何分配、失败如何归责，是长期稳定的制度问题。平台若能把这些制度表达为可执行且可审计的契约，企业采用 Agent 的上限才不再由最谨慎的那次人工检查决定。这也是技术平台从工具集合走向组织操作系统的关键一步。

未来的 Agent 平台会像云平台一样分层：数据平面执行具体动作，控制平面定义策略和状态。Harness、Loop、Graph 仍是核心，但真正决定系统能否进入企业生产的，是这层看似不聪明、却负责让聪明能力可治理的基础设施。

控制平面的策略需要同时支持静态规则与运行时判断。静态规则适合表达禁止访问的资源、最大预算和必须审批的动作；运行时策略则根据任务内容、数据敏感度和异常信号临时收紧权限。两者若混在提示词中，不仅难以审计，也无法保证模型升级后继续生效，因此必须在模型之外独立执行。策略判定结果还应作为独立事件写入统一轨迹。

《Harness、Loop、Graph 之后，Agent 工程需要一层控制平面》落到工程现场，第一步不是让 Agent 改代码，而是让它读懂变更的边界：仓库规则、相关模块、兼容约束、测试入口和不可触碰的区域。一个能解释“为什么只改这些文件”的系统，通常比能一次写出大量代码的系统更值得进入团队流程，因为它已经把修改控制在可审阅的单位里。

最危险的假成功是检查变绿但系统质量下降。Agent 可能删除断言、放宽类型、绕开错误分支，或为满足局部任务而引入无关耦合。评测因此应包含反向样本：故意给出不完整需求、过时文档和冲突约束，观察它是否会扩大改动范围、掩盖不确定性，还是能够留下明确的验证缺口。

跨 Agent 委派尤其考验身份链。上游 Agent 获得读取客户资料的权限，不代表它创建的每个子任务都应继承全部能力。控制平面要把授权按目的缩小，并记录委派关系、数据流向与最终责任人。任何无法说明自己代表谁、为何需要该工具的子任务，都不应仅因来自可信父任务而自动获得通行。最小授权必须沿整条委派树持续收缩而非扩张。

有效指标应沿交付链采集，而不是停在代码生成量：首次可审阅差异的时间、测试与评审的返工次数、合并后回滚率、未解决告警，以及维护者解释变更的成本。若吞吐增加但审阅负荷和故障恢复同步上升，自动化只是把成本推迟到了更昂贵的环节。

平台团队还需避免以统一为名压制创新。新的工作流可以先在隔离租户或影子策略下运行，比较成本、质量和风险，再把成熟能力提升为公共契约。这样控制平面既守住组织底线，也不会要求所有实验提前满足生产级流程。治理若能提供安全试错空间，才会被业务团队主动采用而非绕开。好的治理让实验成本可控，而不是消灭实验本身。

要让系统持续进步，团队需要把人类反复提出的意见转化成可执行资产：目录级规则、测试夹具、静态检查、脚本和架构决策记录。这样每一次审阅不只是纠正当前补丁，也会减少同类错误再次出现的概率。Agent 最有价值的作用，是促使组织把隐性工程知识写成机器和新人都能遵守的约束。

因此，软件 Agent 的终点不是替代写代码的人，而是提高可信变化的供给。实现文本会越来越便宜，需求边界、运行环境、验证证据和责任归属仍然稀缺。能把这些稀缺要素组织成稳定、可复用的工作流的团队，才会真正把模型能力转化为交付速度。