从原型到生产的智能体运维

智能体从原型走向生产，真正难的往往不是“能不能调用工具”，而是出了问题之后，团队能不能知道它为什么这么做、还能不能控制住影响范围。原型阶段，一个 db_query 加上搜索工具，就足以演示从问题到答案的链路；进入业务环境后，这条链路必须变成可观察、可回退、可审计的系统。

先把“会调用”变成“调用得可控”

工具不应只是挂在模型旁边的函数。每个工具都要明确输入参数、权限边界和失败时的处理方式。数据库查询尤其如此：不要让模型直接拥有无限制的 SQL 能力，而应围绕业务动作设计受控接口，例如查询销量、订单状态或库存信息。这样既便于校验，也方便记录每次调用的目的和结果。

搜索和代码解释器同样需要隔离。外部搜索可能返回不可靠内容，代码工具则可能处理危险输入。上线前要做输入校验，并限制工具能访问的数据与资源。模型给出的答案，也最好保留“数据来自哪里”的线索：是内部数据库、公开搜索，还是模型自身的推断，不能混成一句看似确定的话。

生产运维关注的不是一次成功

一个智能体偶尔答对并不代表可用。更有价值的监控，是能看到请求经过了哪些步骤：模型选择了什么工具，工具耗时如何，是否发生重试或回退，最终答案是否使用了空数据。百炼提供调用日志与错误告警，这类能力在生产环境中不应被当作附加项，而是定位问题的基本入口。

当内部数据查询失败时，可以设计搜索回退，但回退不等于随便找个结果填上。系统应明确告诉用户数据来源发生了变化；如果两个来源都无法支持判断，宁可返回无法确认，也不要制造精确但没有依据的答案。成本也需要纳入运维视野，按量调用的模型应配合成本预警，持续观察哪些请求消耗异常。

部署之后，流程仍要能改

使用 Docker 打包智能体，再托管到 ACK 或函数计算，解决的是运行位置问题，并没有解决系统治理问题。模型、工具和业务接口最好分开管理，便于单独替换模型或调整工具逻辑。每次变更都应保留版本记录，并用固定场景检查：数据库为空怎么办，搜索不可用怎么办，模型误判意图怎么办。

从原型到生产，不是把代码放进容器就结束了，而是把一个“会回答问题的演示”变成一个“出了偏差也能被发现和收敛的服务”。智能体越自主，运维边界就越要清楚：哪些决策可以自动完成，哪些必须让人确认，这个问题比模型选得多大更值得先回答。