模型集成与输出治理：把预言放上验货台

引言

城里有一位预言师，能在水面上看见复杂工程的下一步。修桥的人、制钟的人、远行的人都来问她。她说出的建议常常惊人准确，但偶尔也会把西门说成东门，把草图说成定稿。

市政厅没有禁止预言师说话，只是在门口放了一张验货台。每条预言都要先由译员誊清，确认是哪项工程、哪种材料、哪一个仓库。涉及仓库钥匙的预言，还要和账本核对；涉及桥梁承重的预言，要先让工程师签字。

预言师仍然重要。只是从那天起，她的话不再直接变成命令。

模型集成与输出治理，就是这张验货台。

TL;DR

Harness 不能把模型返回当作可信指令。模型集成层屏蔽供应商协议差异，保留能力差异；输出治理层把响应解析成内部消息，再用质量门检查格式、工具、参数、权限、预算和事实依据。模型负责生成候选，治理层决定候选能不能进入执行。

1. Provider 抽象要保留差异

不同模型供应商的消息格式、工具调用、停止原因、流式事件、token 统计都不一样。Provider 抽象的价值，是让运行时用一套稳定协议调用模型，而不是把每家 API 的细节塞进主循环。

但统一接口不能把能力差异抹平。某个模型支持并行工具调用，另一个不支持；某个模型支持流式工具参数，另一个只返回完整 JSON；某个模型能用提示缓存，另一个没有这项能力。抽象层要记录这些能力，让上层根据任务选择合适模型。

多模型支持也不是多写几个客户端。系统还要处理消息历史是否兼容、工具语义能否转换、回退模型是否具备当前任务能力、版本变更后行为是否退化。只看 API 是否可用，会把任务从一个能完成的模型切到一个"活着但做不了"的模型上。

2. 响应解析不能压成字符串

Agent 的一次响应通常不止一段文本。它可能包含用户可见回答、工具调用、工具参数、停止原因、token 使用量和供应商元数据。

如果系统只读取一段字符串，运行时就无法可靠判断：模型是在回答用户，还是请求行动。内部协议应把响应拆成稳定内容块，例如文本块、工具调用块和可选的推理状态块。

流式解析更像状态机。文本片段、工具参数片段和停止事件可能分批到达。解析器要知道当前正在构建哪种内容块、工具参数是否完整、JSON 何时可解析、消息何时可以提交。工具参数只到了一半时，系统不能提前执行。

解析失败也不能用默认值悄悄修补。一个工具参数 JSON 解析失败后，把参数替换成空对象会把协议错误伪装成合法调用。更好的做法是保留错误，让质量门拒绝执行，并把具体失败反馈给模型重试。

3. 质量门挡在执行之前

模型输出是概率生成，工具执行会制造确定性副作用。质量门要站在两者之间。

一次工具调用进入工具层前，至少要过几道检查：

• 格式完整：调用 ID、工具名、参数对象是否存在。
• 工具可用：工具是否在当前会话暴露，是否启用。
• 参数合法：类型、枚举、范围和必填字段是否符合 Schema。
• 业务规则：文件大小、目标域名、金额、任务阶段是否允许。
• 权限安全：当前身份、资源、审批和注入风险是否通过。

任何硬性门失败，都不能继续执行。拒绝结果也要具体：哪一层失败、哪个字段错误、有哪些可选工具、是否允许重试、是否需要用户批准。这样失败才能成为 Agent 循环里的可恢复观察。

质量门不能替代工具层验证。模型输出通过治理后，权限可能变化，资源可能变化，调用也可能来自别的入口。模型边界和工具边界各守一次，才是纵深防御。

4. 推理预算也是治理

更强模型、更深推理、更长上下文通常能提高质量，也会增加成本和延迟。Harness 要在调用前就决定：用哪个模型、给多少输出空间、是否允许工具调用、是否允许回退、超时时间是多少、剩余预算能否支撑下一轮。

预算不能只是记录 token。它要进入控制回路：调用前判断是否允许，调用后记录真实使用，接近上限时降级、压缩或停止。

推理预算也不能替代验证。让模型多想一会儿，可以降低部分错误概率，但不能证明工具存在、参数安全、用户有权限或事实为真。模型的思考是候选，证据和规则才是提交条件。

写在最后

那张验货台后来换过很多木板。预言师也换过几代，水面越来越清，预言越来越细。有人提议把验货台撤掉，因为新预言师已经很少犯错。

老工程师摇头："我们验的不是她聪不聪明。我们验的是仓库钥匙、桥梁承重和已经盖章的账本。"

模型集成层也是如此。模型越强，系统越应该用好它的推理；但只要它的输出会驱动工具、写入状态、影响外部世界，就要先经过协议、解析、质量门和预算。

预言可以启发行动。验货台决定行动能不能发生。