AI 工具流接入与推理服务编排记录

把 AI 能力接进真实业务后，最麻烦的通常不是模型效果，而是整条链路如何保持可观测、可重试、可解释。模型只是其中一环，前后处理往往更占时间。

1. 先画清楚输入、输出和中间态

每次做 AI 工具接入时，我都会先把整个过程拆成几个固定节点：输入采集、参数预处理、推理请求、结果解析、人工兜底和异步通知。

不把中间态定义出来，后面就很难做追踪和重试。

2. 模型调用参数要和业务字段解耦

很多项目一开始为了快，直接把前端表单字段原样传给模型层。短期没问题，但只要提示词策略或供应商接口一改，前后端就会一起被拖动。

更稳妥的做法是先做一层内部参数映射。

3. 不要让前端直接承担推理状态管理

如果推理耗时超过几秒，前端自己轮询和重试通常会很快失控。我更偏向于把任务状态放回服务端，由任务表或工作流负责推进。

type InferenceTask = {
  id: string;
  status: "queued" | "running" | "done" | "failed";
  provider: string;
  inputHash: string;
};

4. 结果清洗比提示词更稳定

模型输出结构即使设置了 JSON 模式，也不一定完全稳定。比起不断堆提示词，我更愿意在后端做一次明确的 schema 校验和字段清洗。

5. 回调链路必须有签名或密钥校验

只要有异步回调，就一定要有最基本的校验措施。否则后续很难区分是真实回调、重复回调还是伪造请求。

6. 人工兜底不要等失败后才考虑

很多 AI 工具流上线时只考虑“模型成功”的路径，等出现失败或低质量结果才想加人工审核。这样通常会补得很狼狈。

我现在会在第一版就预留状态：待审核、需重试、人工修订。

7. 成本统计最好从第一天就记录

不管接哪个模型供应商，调用量、耗时、单次成本都值得落库。不是为了计费，而是后面做路由切换和降级策略时能有依据。

总结

AI 工具流真正难的是把模型能力放进一条可靠的业务链路里。只要状态、回调、校验和兜底这几块先设计好，后续替换模型或调整提示词都会轻松很多。