计量表一直在运行

首个昂贵的智能体运行并不像治理问题，而更像账单问题。团队在计量表开启后收到第一张智能体发票，按成本排序后，发现某个运行的成本是中位数的40倍。提供商计量表显示令牌和总额，应用日志显示请求成功，追踪查看器显示简洁的请求与响应。没有任何一项能解释为什么这个运行耗时漫长而其他运行干净利落。

在我之前的文章《补贴结束：使用工具的智能体实际成本》中，我论证了基于用量的计费并未让智能体变得昂贵，而是让既有成本变得可见。账单并未变大，只是变诚实了，而诚实的账单是你可以针对其进行工程优化的。

但可见不等于可归因。要归因使用工具的智能体的成本，你必须看穿产生成本的运行内部。一旦建立这种可见性，你就会发现成本只是问题首次变得可见的地方。成本激增、不安全委托和失控动作是不同的失败，但它们暴露了同一个缺失的层：控制平面无法治理它无法独立观察的循环。

账单是诚实的，但未加解释。发票上的数字没错，只是不完整。提供商计费可以告诉你消耗了什么，但通常无法告诉你平台内的哪个设计选择导致了消耗。应用日志可以告诉你外部请求是否成功，但往往无法告诉你智能体是如何到达那里的。这让团队对着账单争论不休，而他们真正需要的是审计追踪。

所谓控制平面，是指单个智能体之上的平台层，组织在此集中观测并实施策略、访问、预算、路由和执行约束。多数组织已拥有该层的部分组件。但它们常常缺失的是其下的证据层：记录智能体实际做了什么、逐轮递进的循环感知记录。

控制平面是策略决策所在。观测基座是控制平面读取的证据。检测点是智能体无法绕过的运行时关卡：模型网关、工具代理、API网关、执行沙箱、运行时框架和策略引擎。

许多组织检测了应用边界，随后部署了实际工作在循环内完成的系统。结果是控制平面有观点但证据不足。

循环是观察的单位。以下是空追踪背后的错误：智能体可观测性常被当作应用可观测性的加重版，但它的形状完全不同。工作单位改变了，而检测没有。传统服务处理请求并返回响应；请求是自然追踪单位。智能体并非处理请求，而是朝着结果工作。它推理、调用工具、读取结果、再次推理，直到决定完成、触及边界或升级。单一用户意图可能扇出多个模型调用、多个工具调用，以及每轮变化的上下文窗口。重要的信号是这些轮次之间的关系，而非任何一轮的时序。

由此得出三件事，每件都打破了应用监控默默依赖的假设。第一，上下文是累积状态，而非固定载荷。每轮可能携带先前的消息、工具描述、检索文件、中间结果和早期决策。你必须能够逐轮观察状态增长，因为增长正是成本和风险所在。第二，工具调用是一级决策，而非实现细节。模型选择了哪个工具、传入了什么参数、结果多大、策略是否约束了调用，都是治理记录的一部分。路由准确性和路由成本是从两个方向审视的同一审计。第三，每个运行都可能成为自己的追踪树。相同的提示周二可能走与周一不同的路径，因此固定的调用图和干净的服务映射假设了智能体可能不具备的规律性。如果观察单位仍是请求，你会看到10,000次成功调用，却从未注意到那一次本应三轮却跑了十五轮的循环。

一旦你接受循环是单位，需求就变得具体。你需要智能体下方捕获的少量特定信号，并存储于可跨整个舰队查询的位置，而不仅仅是每运行查看器内。在我为某大型医疗机构运行的试点中，我们首先建立了这一层，基于OpenTelemetry、Cloud Trace和数据仓库中的用量日志表。具体技术栈不如形状重要，其可推广性远超该场景。

每个用户意图至少应产生一个运行追踪。每个循环轮次应表示为跨度或稳定分组属性。模型调用、工具执行、策略检查、重试和后处理应作为该轮下的子跨度或结构化事件。确切的命名约定不如保留循环的因果结构重要。

信号 控制平面为何需要它 示例字段 运行和轮次结构让运行作为因果树而非扁平调用列表可读 run_id, turn_id, parent_span_id, timestamp 令牌和模型核算使成本可逐轮、逐模型、逐工具路径解释，而非仅仅在聚合中可见 model, input_tokens, output_tokens, cached_tokens 工具调用事件记录委托决策，识别过大或重复的工具结果 tool_name, parameter_shape, result_bytes, row_count 护栏决策事件显示哪些控制触发，是允许、拒绝、重写、约束还是升级了动作 policy_id, policy_decision, reason_code, enforcement_point 身份和权限上下文重建工作运行于谁权限下、当时适用哪个数据范围 principal_id, delegated_scope, service_account, data_scope 结果和边界元数据区分干净完成与重试、边界命中、升级和用户可见失败 turn_count, stop_reason, loop_bound_hit, payload_cap_hit, outcome_status 这些都不稀奇，实际设计工作不是发明新的遥测原语，而是管理基数、保留、载荷捕获、采样策略、模式演化，以及追踪数据、用量数据、身份数据和策略数据之间的连接。

存储点是团队低估的部分。如果这些信号仅落入追踪查看器，你可以精美地检查一个运行，却永远无法推理一千个。治理是舰队问题，而非单次追踪问题，因此基座必须可查询。

它还必须以数据最小化为设计原则：默认捕获元数据，例外捕获内容。记录工具调用不意味着存储每个原始提示、完整结果集、凭据、机密文档或敏感参数于追踪中。在监管环境中，有用的模式是将元数据与载荷分离：工具名称、模型、令牌计数、载荷大小、行数、策略决策、权限上下文、请求ID，以及必要时遮蔽或哈希的参数值。目标是足够重建运行行为的证据，而非智能体所见一切的失控存档。

第一个有用版本不需要完整提示捕获或语义评估。有了run_id、turn_id、parent_span_id、timestamp、principal_id、delegated_scope、model、input_tokens、output_tokens、cached_tokens、tool_name、result_bytes、row_count、policy_id、policy_decision、stop_reason、loop_bound_hit和outcome_status这些列，昂贵的循环不再是谜题，而是查询。

确切的语法因仓库而异，但治理问题应能不通过人工点击单个追踪查看器而表达：

with runs as ( select run_id, count(distinct turn_id) as turns, sum(input_tokens + output_tokens) as total_tokens, max(result_bytes) as largest_tool_result, bool_or(loop_bound_hit) as hit_loop_bound, count_if(policy_decision = 'rewrite') as rewritten_actions from agent_turn_events where occurred_at >= current_date - interval '7 days' group by run_id ) select * from runs where turns > 10 or largest_tool_result > 10000000 or hit_loop_bound or rewritten_actions > 0;

这就是欣赏一个追踪与治理一个舰队的区别。

在旧追踪中，开篇的昂贵运行仅仅是昂贵。在循环感知追踪中，它变得可读：第3轮检索了80,000行，第4轮携带该结果前进，第5轮选择了昂贵模型，第6至11轮以略微不同的参数重试同一工具调用，运行最终因触及循环边界而非干净完成而停止。运行不再是谜题，而成为记录。

一个基座，三个治理问题。值得一次正确构建的原因在于，同一基座回答了行业常分开处理的三个智能体治理问题：成本管理、委托与访问控制、失控行为预防。它们并非相同的失败，但需要同类的证据。

治理问题 控制平面需要的证据 成本 轮次数、令牌数、模型选择、上下文增长、工具结果大小、重试和停止原因 委托 主体、委托权限、数据范围、所选工具、动作参数和策略决策 失控行为 重复动作、循环边界、载荷上限、护栏决策、被拒绝或重写的动作以及结果状态 成本是第一个问题，通过每轮的令牌核算，你终于能回答运行为何昂贵。你可以看到成本是来自过多的轮次、携带的上下文过多、工具结果过大、在错误步骤使用了昂贵模型，还是应该被限制的重试循环。

委托与访问是第二个且更棘手的问题。在多智能体系统中，委托是安全边界。企业最终会被问及谁授权了某个智能体动作、它在谁的权限下运行、当时适用哪个数据范围。这个问题的审计追踪正是同一追踪，增加了每轮的身份和权限信息。

失控行为是第三个问题。破坏性删除成为传说的故事、试图删除生产表的智能体、重复发出同样昂贵扫描的循环，不应只存在于事后分析中。在此模型下，被阻止的破坏性语句是一个护栏决策事件，带有拒绝标签；失控扫描则是一个触及循环边界或载荷上限的追踪。有趣的治理信号是确定性控制所拒绝的危险动作。

三个对话，一个立足点。循环是治理的单位，因为循环是成本累积、权限行使、工具选择、控制触发和结果显现的地方。

智能体不能自己保管记录。有一个诱人的捷径：让智能体自己记录令牌、权限和被阻止的动作。但那是不安全的，因为智能体可能在被破坏时篡改记录。更根本的是，如果治理依赖智能体自身的日志，那么你正在用无法独立验证的组件进行审计。控制平面必须从智能体无法干预的层级读取证据，这就是为什么检测点必须是运行时关卡。

智能体可以对其内部状态提供有用的信号，但治理层永远不应依赖智能体作为其记录的最终仲裁者。将记录委托给被治理的实体是混淆控制平面和监督对象。