AI Agent 工程化生存指南（1）：为什么总是能 Demo 不能上线？先画清 4 条边界

过去几个月，AI Agent 是技术圈最热的词之一。几乎每个团队都能做出一个“看起来很聪明”的 Demo：能理解需求、会调用工具、还能自动执行任务。

但一到上线，就开始出现熟悉的问题：

• • 成本飙升，结果不稳定

• • 偶发错误无法复现

• • 一遇到异常就卡死或乱执行

• • 最后变成“人工盯着它跑”的半自动系统

很多人第一反应是模型不够强。但我这段时间看下来，绝大多数问题并不在模型，而在工程边界没有设计清楚。

一句话概括：模型能力决定上限，边界设计决定下限。

一、能力边界：模型该思考，系统该执行

最常见的错误，是把模型当流程引擎。让它既理解需求、又做规则判断、还直接执行写操作。

这会带来两个问题：

1. 1. 可验证性差：你无法证明它每一步都正确。

2. 2. 可复现性差：同样输入，结果可能不一致。

更稳的做法是分层：

• • 模型：负责意图理解、任务拆解、异常解释

• • 工具：负责查询、计算、写入、调用 API（确定性）

• • 编排：负责顺序、重试、超时、幂等、权限

经验法则：能写成函数的逻辑，就不要让模型猜。

二、状态边界：别把上下文窗口当数据库

很多 AI Agent 一开始表现不错，跑几轮后越来越“健忘”或“跑偏”。根因通常是状态混乱：历史对话、用户偏好、业务事实全部塞进上下文。

正确做法至少拆三层：

• • 会话状态：当前任务临时状态

• • 用户记忆：用户长期偏好与固定约束

• • 事实来源：业务事实源（数据库/知识库/API）

如果不分层，系统会出现两个后果：

• • 无法判断“事实”到底来自哪里

• • token 成本不断上涨，质量反而下降

用户请求

规划模型

会话状态

用户记忆

事实来源

工具与 API

最终动作

三、控制边界：自动化必须有刹车

AI Agent 真正危险的不是“答错一句话”，而是“做错一个动作”。尤其是写操作、批量操作、外部系统调用，没有控制边界迟早出事故。

上线前至少要有三道闸：

• • 权限闸：谁能调用什么工具

• • 风险闸：高风险动作必须审批

• • 回退闸：失败后可回滚，有审计链路

我的简单策略：读操作自动化，写操作审批化，外部调用限额化。

四、可靠性边界：Demo 成功不等于系统可运营

很多团队把“跑通一次”当成功标准。但线上世界只看两件事：会不会失败？失败后怎么办？

最小可运营清单：

• • 重试：错误分类 + 指数退避 + 幂等保护

• • 降级：模型超时后走保守路径

• • 观测：日志、trace、调用链、token 与成本

• • 评估：任务成功率、人工接管率、单位任务成本

没有这些，AI Agent 只是会动的 Demo，不是可交付系统。

一张图看懂：上线前的 4 边界体检

否

是

否

是

否

是

否

是

AI Agent 项目

能力边界清晰

风险: 把确定性逻辑交给模型猜

状态边界分层

风险: 上下文污染, 成本失控

控制边界完善

风险: 执行动作不可控

可靠性边界完整

风险: 能 Demo 不能运营

可上线的 AI Agent 系统

结语：别先问模型够不够强，先问边界清不清楚

如果你现在正在推进 AI Agent 项目，建议先做一件事：拿这 4 条边界过一遍现有流程，补齐最薄弱的一环。

因为 AI Agent 从“会 Demo”到“能上线”的关键，不是换模型，而是把边界工程化。