一个能进生产的智能体和一个能演示的智能体，差距不在于模型，而在于四件事：读得懂你的资料、调得动你的系统、出错时兜得住、上线后管得住。
一、模型不知道你公司的事
通用大模型没读过你的产品手册、报价单、历史工单和内部制度。直接问它，它只能编。这是 RAG 要解决的问题——把资料切分、建索引，回答时带出处引用。
但很多项目在这里就止步了：知识库建好了，问答也能跑，然后呢？智能体依然只会回答问题，不会办事。
二、只会说，不会做
真正产生价值的是动手办事：查库存、建工单、发通知、更新 CRM。这需要给智能体接上工具（Function Calling 或 MCP 协议），让它能安全地调用业务系统 API。
「安全地」是关键词。工具层至少要有三道约束：
- 可审计：每次调用记录参数与结果，出问题能回溯
- 可限流：防止异常循环把下游系统打垮
- 可回滚：写操作要么幂等，要么有明确的撤销路径
三、不敢放到客户面前
上线的真正阻力往往不是技术，而是一句话：万一它说错话怎么办。这个担心是合理的，需要用工程手段回应，而不是靠承诺。
01
输入输出护栏敏感话题、竞品诋毁、超范围承诺在进出两端拦截。
02
关键动作人工确认涉及金额、合同、对外承诺的操作强制停下来等人点确认。
03
全量留痕每轮对话、每次检索、每次工具调用都记录，出问题能定位到具体环节。
这三层的价值不只是防错，更是让业务方敢签字上线。很多项目死在最后一公里，就是因为没人敢为「万一」负责。
四、上线后管不住
大模型不是确定性系统，同样的输入可能给出不同的输出。这意味着上线不是终点，需要持续观测：
效果按评测集定期回归，模型升级、提示词调整后都要重测
成本按场景统计 token 消耗，识别异常昂贵的调用路径
质量抽样人工复核，收集用户负反馈补充进评测集
可用性延迟、失败率、降级触发次数纳入监控告警
怎么避免走到这一步
一个务实的建议：不要一上来就做大而全的智能体平台。先挑一个人力消耗最大、规则最清晰的单一场景做透，两周内跑出可试用版本，用真实问题集验证效果，再决定要不要扩大。
规则清晰意味着好评测，人力消耗大意味着 ROI 明显。这两个条件同时满足的场景，成功率远高于「我们想全面 AI 化」这类立项。