多接几家模型后，网关很容易加一条“失败就切下一个”的逻辑。它能缓解单供应商不可用，却不是完整路由：备用模型可能不支持 function calling、上下文不够、数据地域不合规，或者虽然 HTTP 成功，业务输出已经无法使用。

我把路由分成两步。先用硬约束过滤出“有资格执行”的模型，再在候选中按具体任务的成功率、延迟和成本选择。fallback 也必须重新通过硬约束，不能为了可用性把安全与能力要求降掉。

给 Agent 配一份“可用工具列表”，只能说明模型可以看到哪些函数，不能说明用户有权对哪些对象做什么。一个用户能调用 rerun_job，不代表他能重跑所有项目、所有环境的任务；能调用 query_table，也不代表能读每张表的每个字段。

我把工具权限表达为 subject × action × resource × context。主体来自可信会话，动作来自已注册工具，对象必须解析为稳定 ID，上下文包含租户、环境、时间和资源当前状态。模型只提出参数，不参与最终授权结论。

RAG 团队常用一张端到端准确率报表：问题发进去，答案对就记 1，错就记 0。这个数适合看整体趋势，却不能告诉我们该改 embedding、chunking、reranker、Prompt 还是知识源。

我会把评测拆成三层。第一层只测检索是否拿到充分证据；第二层固定正确证据，只测模型能否组织出正确、受引用支持的答案；第三层才跑真实端到端链路，验证两者组合后的延迟、成本和失败分布。

Prompt 从十几行增长到几百行后，很容易变成一份“谁都能改、没人敢删”的线上配置。有人为了修一个格式问题加两句指令，第二天工具选择率下降；回滚时只把文本改回去，结果仍和上周不同，因为模型别名、工具 schema 或检索模板已经变了。

我不把 Prompt 单独视为版本单位。真正决定一次模型行为的是完整运行组合：system prompt、消息模板、模型 snapshot、sampling 参数、工具定义、检索/上下文策略和输出 parser。它们一起形成不可变 Bundle，发布与回滚都指向 Bundle ID。

SQL Copilot 最容易做成“代码补全器”：模型返回 SQL，编辑器高亮一下，用户自己运行。到了需要自动修复、自动解释或一键执行的场景，这个边界就不够了。模型写出的 SQL 往往像标准 SQL，真正交给 Flink、Spark、Hive 或 PostgreSQL 时，方言、Catalog 和执行计划都会给出不同结论。

我把验证分成三段：目标引擎 Parser 证明语句属于这个方言，Catalog/Analyzer 证明对象和类型能解析，Planner/受控执行证明计划风险和结果语义可接受。任何一段失败，都返回具体证据，而不是笼统说“SQL 可能有问题”。

模型开启 stream=true 后，客户端能更早看到文字，接口看起来只是从一次 JSON 响应变成多次回调。实现里最常见的 bug，是每收到一个网络 chunk 就 JSON.parse，或者把每个 data: 行当成完整业务消息。

TCP/HTTP 传输分片、SSE 事件和模型增量是三层边界。它们恰好可能对齐，但协议从未保证对齐。我会先把字节流解析成完整 SSE event，再把供应商 event 归一化，最后由状态归并器构造答案。

模型网关第一版通常很像反向代理：统一鉴权，替换 endpoint，把 messages 转给不同供应商。真正接入多个模型后，会发现最难的不是请求字段，而是每家对流式增量、结束原因、工具调用、错误和用量的表达都不同。

如果网关只输出一套“看起来统一”的 JSON，却不保存转换前证据，线上出现空回答、工具参数残缺或 HTTP 200 后中途断流时，无法判断问题来自供应商、适配器还是客户端。我会同时保留原生协议轨和统一语义轨，两者用同一个 request ID 关联。

OpenAI 昨天发布 Function Calling 后，模型与外部工具之间终于有了比“在文本里吐一段 JSON”更明确的接口：开发者描述函数，模型可以选择函数并生成参数。这个能力会明显降低 Agent 工具接入成本，但它解决的是参数生成，不是安全执行。

我会把模型输出叫作 tool call proposal。它必须经过协议、业务、权限和风险检查，才会变成真实调用。少了这层执行契约，JSON 越稳定，错误动作反而越容易自动落地。