有个常见场景：一个 AI Agent 在 demo 里跑得很好。客户的 PoC 看完点头，签字预算到位。三个月后切到真实生产数据，第一周就开始出问题——agent 回复偶尔带错关键参数、审计复盘找不到根因、客服工单堆在那里没人接手。

Demo 跑得好不等于能上线。中间隔着六个支柱。涌意把这六支柱固定成一个产品化的审查框架。

支柱 1：接地与数据完整性

Agent 给出的每条关键事实都要落到真实数据上。问题不在「用了 RAG」还是「用了 tool calling」，而在数据被切割时是不是按字段压缩——不能拦腰截断结构。当工具返回的数据超出上下文预算，agent 必须明确告诉模型「这是部分结果」，而不是装作完整。

引用一定要给到具体来源，让审计的人能点进去看。数字一定要从系统计算来，不能让模型从部分视图里推断。

支柱 2：Tool-calling 架构

系统能精确算出来的数据，不要用文档检索去近似。Tool 应该是模型显式调用的，不是默默注入每个 prompt 的。结构化输出走 schema-constrained，不要用 free-form JSON。Tool 签名严格校验，调用循环有上限。

有固定的 eval 集，每次 prompt、tools、model version 变动都自动跑。Pin 住 model/provider 版本——切版本必须过 evals。LLM-as-judge 必须校准过人工标签。低于阈值阻止发布。

每次工具调用记下参数和结果，关联到运行 ID。每一步记下 provider/model/version。三个月后一个具体决定能从日志完整重现。日志 append-only 或 tamper-evident。敏感数据按策略脱敏。

写操作必须带幂等 key，避免重试导致重复下单或重复发邮件。高风险操作要人工确认。工具调用要做权限校验。失败中途留下的状态是确定的，不是悬浮的。

有每次运行和总 token 预算，超出时按预定降级路径走（截断 vs. 拒绝），而不是默默继续烧钱。简单步骤走小模型，复杂步骤才走贵模型。Provider 失败有 fallback。每次会话成本可测。

涌意的「AI Agent 生产就绪审查」产品就是按这六支柱给你的系统打分。两周交付，固定价 ¥35,000。产出：readiness scorecard、P0/P1/P2 findings、修复 roadmap。Demo 跑得好的部分我们说出来，跑不通的部分说出来差在哪、怎么补。