通过受治理运行时运行实时代理时，有三件事让我们感到意外

**背景** 我们一直在运行一个实时分析代理处理真实市场数据，执行过程通过一个受治理运行时进行路由：预算限制、语义分类以及在到达外部系统之前网关处的执行控制。我们对推理步骤进行了受控实验，以了解当分析遇到执行时实际上会出什么问题——不是抽象层面的提示质量，而是下游系统能否可靠地基于模型输出采取行动。 **三件让我们感到意外的事** **1. 提示结构驱动了执行可靠性，而非推理质量。** 我们在相同数据上比较了严格的JSON输出和自由形式的自然语言分析——各运行10次。 * 严格JSON：**10/10** 解析成功 * 自由形式：**0/10** 解析成功 自由形式的响应通常很有思想——多场景分析、条件性观点、细微的不确定性。但我们的管道无法消费它们。可靠性不在于模型是否理解问题，而在于输出是否符合执行的期望。 **2. 提示结构似乎影响了决策分布，而不仅仅是输出形式。** 我们添加了第三种变体：自由形式推理，末尾附加一个结构化JSON块。相同数据，相同模型。确切分布在不同实验运行中有所变化，但即使输入相同，不同格式的输出始终存在差异。严格的模式似乎将多场景推理压缩为单一强制方向。我们不仅仅是在改变序列化——我们可能已经改变了代理本来会做的事情。 **3. 推理和提取可以分离。** 我们将其拆分为两个显式调用：代理A进行自由形式推理；代理B读取A的输出并仅生成严格的JSON。代理B保持了**10/10**的解析成功率，而代理A保留了丰富、有时相互矛盾的分析。提取出的指令始终是机器可读的，即使A的散文中包含多个条件场景，没有单个标签能够涵盖。各层有不同职责。 **要点** 我们现在考虑三个层次： * **推理** — 开放式分析、不确定性、多场景 * **提取** — 管道可解析的结构化输出 * **执行** — 治理边界，预算、语义和授权真正发挥作用的地方 我们当前的工作假设是，治理应最接近执行，即决策转化为行动的地方。试图治理自由形式的推理感觉像是错误的层次。在执行边界治理结构化负载则感觉很合适。 **向在场各位提问** 目前你们是如何处理生产代理的执行控制、工具授权和治理的——在提示中、在中间件层、还是在工具边界？想知道哪些方法有效，哪些仍然是用胶带凑合的。