企业官网建设流程全解析

严格 Schema 写对了，落地仍常卡在「可复用模板」这一环。

若你也在补 Agent / 评估骨架，可先看爱发电周报（¥19）或主页三件套：
https://afdian.com/item/f8fc6f70c77411f18d1052540025c377
主页总览：https://afdian.com/a/laoyinai

摘要：Agent 工具调用常因类型漂移、缺字段或业务拒绝失败，团队却习惯「再调 Prompt」。厂商strict: true用语法约束采样保证参数符合 Schema，但业务校验、权限与幂等仍在应用层。本文区分事实与分析，给出校验、有限纠错重试与幂等步骤，说明这往往比再堆 Prompt 更关键。

标签：人工智能·AIGC·机器学习·云计算·安全

开篇

【分析】Demo 里工具调用「大多能跑」；一旦进入多步 Agent、写操作与权限边界，失败模式就变成：字符串冒充整数、可选字段乱飘、业务状态不允许却仍被执行。运维看到的是反复超时与重复副作用，产品侧则把锅甩给「模型不够听话」——然后继续改 System Prompt。【分析】问题不在「要不要写清楚说明」，而在于自然语言约束无法充当运行时类型系统：说明越长，越难回归测试，也越难把失败归因到具体字段。

【事实｜厂商文档】Anthropic 在工具定义上设置strict: true，通过 grammar-constrained sampling（语法约束采样）保证工具input符合input_schema；文档举例：预订系统需要passengers: int时，无严格模式可能得到"two"或"2"，开启后则保证为整数2。Schema 需配合additionalProperties: false；计算机使用与浏览器工具集条目不接受strict: true（Strict tool use）。【事实｜厂商文档】OpenAI Function Calling 同样支持strict: true，并建议始终开启；此时每个 object 的additionalProperties须为false，且properties中字段须全部列入required（可选字段用type: [T, "null"]）。文档还区分 Structured Outputs（保证符合 Schema）与仅 JSON Mode（只保证合法 JSON、不保证 Schema）（Function calling、Structured Outputs）。【分析】「再调 Prompt」抬的是自然语言约束；严格 Schema + 应用层校验守的是可执行合约——下文按问题机制、落地步骤与局限展开。与专栏 10-12「执行边界」一文分轨：本文只谈调用参数与纠错回路，不展开沙箱/工具网关。

问题与技术变化

「看起来像 JSON」不等于「能安全执行」

【分析】工具调用失败在日志里常被记成「模型抽风」。拆开看，至少有三层：①形状层——类型错、缺必填、多出未知字段；②语义/业务层——权限不够、状态机不允许、值域越界；③副作用层——重试导致重复扣款/重复发单。Prompt 擅长描述意图，却很难稳定压住①；即便压住①，②③ 仍须代码与状态存储兜底。【分析】把三类问题都塞进「再写一句 please return valid JSON」，会同时制造：不可测的 Prompt 漂移、无结构化错误反馈、以及写路径上的盲目重试。【分析】更隐蔽的一点是：形状错误有时会被下游「碰巧吞掉」（字符串转数字、缺省填充），Demo 看起来绿了，生产却在边界输入上爆出重复写或越权——这正是「只靠 Prompt + 侥幸解析」最危险的地方。

厂商 Strict：先把「参数形状」钉死

【事实｜厂商文档】Anthropic Strict Tool Use 的保证是：工具input严格遵循input_schema，且工具name始终有效；实现路径是把 schema 编译进语法约束采样流水线（与结构化输出同管线）。文档用例要求顶层strict: true，并在input_schema中设置additionalProperties: false（出处同开篇 Anthropic 文档）。【事实｜厂商文档】OpenAI 侧，strict: true依托 Structured Outputs；不满足additionalProperties: false与「全部 required」时，请求会被拒绝并返回约束缺失细节。文档明确推荐始终启用 strict；并说明 Structured Outputs 是 JSON Mode 的演进——后者只保证合法 JSON，前者保证 Schema 遵从（出处同开篇 OpenAI 两篇文档）。【事实边界】上述为保证「参数符合所声明 Schema」的厂商能力描述，不是跨厂商 SLA，也不是「业务一定正确」的承诺；computer/browser 等特殊工具集对 strict 的支持以各厂商当前文档为准。

【分析】落地含义是：能开 strict 的自定义函数工具，默认打开，把类型与必填从「希望」变成「合约」。但 Strict只管形状：它不会替你做 RBAC、不会判断订单是否可退、也不会自动生成幂等键。流水线应是：模型输出 →（可选）厂商 strict 约束 → 解析 → Schema 校验 →业务校验→ 执行；写操作旁注幂等键，避免重试放大副作用。【分析】实践上建议把「Schema 校验」与「业务校验」分成两个明确阶段并分别计量失败率：前者多指向工具定义/模型遵从问题，后者多指向产品规则与权限配置——混在一个invalid_argument里，排障会重新退回猜 Prompt。【分析】与专栏 10-14「观测」一文分轨：Tracing 回答「这一次走了哪条路径」；本文回答「参数进执行前如何过闸」——可共用 call id，但不要把校验逻辑塞进 exporter。

纠错：结构化错误回灌 + 有限重试，而不是再堆 Prompt

【分析】校验失败时，正确回路是：把具体错误（字段路径、期望类型、业务拒绝码）作为 tool result / 校验消息回灌模型，允许1–2 次受控重试；仍失败则停机并告警，而不是无限循环或「加强语气」。【分析】对照「只调 Prompt」：左侧常见死循环是失败 → 改 Prompt → 再调 → 仍失败，缺少退出条件与结构化反馈，成本与不确定性同步上升。右侧用实线主路径 + 虚线有限回灌表达受控纠错——虚线不是无限重试的许可证。【分析】有限重试的「有限」还包含预算：每次回灌都会再消耗一轮模型与工具配额；对写工具，重试前必须先确认幂等键已占位，否则「纠错成功」可能只是把重复副作用换了一种姿势执行。【预测】在工具面周更、写操作增多的团队里，先固化 Schema/业务校验与幂等，再谈 Prompt 文案打磨，比反过来更不容易把生产排障变成「玄学调参」。

开发者视角

【分析】更稳妥的落地顺序不是「先把 Prompt 写到极致再谈 Schema」，而是先定合约与失败策略，再收紧 Prompt。以下清单可直接贴进迭代看板：

1. 能开就开strict: true：自定义 function/tool 默认严格模式；对照厂商限制（如 Anthropic 的 computer/browser toolset 不接受 strict）做例外清单。
2. Schema 写死形状：additionalProperties: false；OpenAI strict 下 properties 全进required，可选字段用type: [T, "null"]；枚举约束非法状态。
3. 应用层业务校验不可省：权限、租户隔离、状态机、值域与跨字段规则——Strict 通过后仍要过闸。
4. 失败回灌要具体：返回字段路径 + 期望类型/拒绝原因；禁止只回"invalid"或静默丢弃。
5. 有限重试：同一 tool call 纠错重试上限 1–2 次；超限停机、告警、可人工介入；禁止盲目全量重放。
6. 写操作强制幂等键：request_id/ idempotency key 落存储；重试命中同一键不产生第二次副作用。
7. 区分 Structured Outputs 与 JSON Mode：需要对齐 Schema 时用前者；不要误以为「能 parse 成 JSON」就等于可执行。
8. 验收窄域：选一条「读工具 + 写工具」：故意喂类型错误与业务拒绝，确认 strict/校验拦截、回灌可触发有限重试、写路径幂等生效后再扩工具面。

【分析】验收上建议同时盯：strict 未开的工具占比、业务校验误报/漏报、重试是否突破上限、幂等键冲突率，以及 Prompt 变更是否仍被当成「修类型错误」的主手段。【分析】排期上可先覆盖高频写工具与资金/订单类副作用，再铺到只读检索工具；过早把全部精力花在 Prompt 示例堆砌，通常只会延后真正的合约建设。【分析】对多模型路由的团队，还要把「该模型是否支持等价 strict」写进路由表：切到不支持或不完整约束的后端时，应用层 Schema 校验必须升格为硬门禁，而不是假设「换模型后形状仍然免费正确」。【预测】工具数量继续上升时，没有 Schema+校验+幂等的 Agent，故障会从「偶发抽风」变成「系统性不可审计」。

局限与不确定性

1. Strict 能力因工具类型而异：如 Anthropic 文档写明 computer/browser toolset 不接受strict: true；例外要进清单。【事实边界】
2. Schema 子集与缓存行为以厂商为准：支持的 JSON Schema 特性、首次编译延迟、缓存与数据保留条款可能演进；跟 changelog。【事实边界】
3. 形状正确 ≠ 业务正确：Strict 不替代权限、合规与状态机。【分析】
4. 回灌可被模型「绕开」叙述：仍需服务端强制校验，不能只信模型自检。【分析】
5. 重试上限与幂等是工程选择：1–2 次为经验默认，需按 SLA 与副作用成本调参。【分析】
6. 执行边界另文：沙箱、工具网关与出站策略见 10-12 专栏，本文不展开。【分析】

主要参考资料

1. Anthropic，《Strict tool use》（中文）：https://platform.claude.com/docs/zh-CN/agents-and-tools/tool-use/strict-tool-use
2. OpenAI，《Function calling》：https://developers.openai.com/API/docs/guides/function-calling
3. OpenAI，《Structured model outputs》：https://developers.openai.com/api/docs/guides/structured-outputs

——
可落地配套：
· 评测周报 ¥19 https://afdian.com/item/f8fc6f70c77411f18d1052540025c377
· 摘要样刊 ¥12 https://afdian.com/item/1a923b60c77511f1bb3352540025c377
· 模板三件套 ¥49 https://afdian.com/item/313b5ee4c6af11f18d555254001e7c00
· 主页 https://afdian.com/a/laoyinai
· 开源评测骨架 https://github.com/yin36563-prog/eval-harness-lite