从 POC 到上线：Agent 项目最大的技术断层在哪里？

作者:WiseAgent小而美智能体架构师
过去这一年，我见过太多死在 Demo 阶段的 Agent 项目。老板在会议室看 POC（概念验证）演示时，掌声雷动：Agent 能够流畅地查询数据库、写代码、甚至还能讲个笑话。大家觉得，“这事儿成了，下周上线。”

作为技术负责人，这时候我通常会泼一盆冷水：“现在的完成度只有 20%，剩下的 80% 是为了填补‘概率’与‘工程’之间的深渊。”

POC 和生产环境（Production）之间，隔着的不是几个 Prompt 的优化，而是从“概率性艺术”到“确定性工程”的范式转移。在我的工程实践中，我发现这个断层主要集中在三个维度：架构的解耦、边界的收敛、以及评估的量化。

断层一：架构的解耦——别把 GPT-4 当万能胶

在 POC 阶段，为了快速出效果，最常见的做法是写一个几千字的“上帝 Prompt”（God Prompt），然后挂载十几个 Tools，直接扔给 GPT-4。

这种做法在生产环境是灾难性的。

1. 成本与延迟的不可承受：每次用户说个“你好”，你都要带着几千字的 System Prompt 去跑一遍 GPT-4。Token 费用在燃烧，用户在转圈等待。

2. 注意力涣散：当工具超过 5 个，或者 Prompt 超过一定长度，模型的指令遵循能力会非线性下降。它开始胡乱调用工具，或者忽略你的安全指令。

工程化解法：拆解与路由

上线前，我做的第一件事通常是**“把大模型拆小”**。

• 分层架构：引入一个极轻量的 Router（路由）层。用户进来先用小模型（甚至关键词匹配）判断意图。是闲聊？是查数？还是写代码？

• 专人专事：

  • 闲聊 -> 路由给 7B 参数的小模型或微调模型。

  • 简单查询 -> 路由给专门的 SQL Agent。

  • 复杂推理 -> 才舍得调用 GPT-4 或 Claude 3.5。

• Prompt 模块化：没有任何一个 Prompt 应该超过 1000 tokens。Agent 的记忆里只加载当前任务必须的上下文，而不是把祖宗十八代的聊天记录都塞进去。

一句话总结：POC 是用一个天才解决所有问题；生产环境是用一群流水线工人配合一个专家来解决问题。

断层二：边界的收敛——把 LLM 的输出视为“不可信输入”

POC 阶段，我们测试的是Happy Path（快乐路径）。测试人员很配合，问的问题都很标准，Agent 表现得很完美。

生产环境，我们面对的是Corner Case（极端情况）和恶意攻击。用户会输入乱码、会诱导攻击，或者 API 刚好超时了。这时候，完全依赖 LLM 自愈是不现实的。

最大的断层在于：开发者依然把 LLM 当作“函数”来用，默认它返回的一定是合法的JSON。

工程化解法：防御性编程与强校验

在我的代码里，LLM 的输出地位等同于**“用户提交的表单”**——默认是脏的、不可信的。

1. 结构化强校验：不要只在 Prompt 里写“请返回 JSON”。必须在代码层用 Pydantic 或 Zod 做强类型校验。如果字段类型不对，直接抛错或触发重试，绝对不能透传给下游业务。

2. 有限状态机（FSM）兜底：我反复强调，Agent 的流程控制不能全靠 LLM 的“脑补”。

   1. POC做法：让 LLM 决定下一步干嘛。

   2. 上线做法：代码里写死状态机（State Machine）。如果当前是“支付中”，LLM 就算想去“查天气”，代码逻辑也要把它按住，强制它留在支付流程里。

3. 熔断机制：当 Agent 陷入死循环（比如反复调用同一个工具报错）时，必须有计数器强制熔断，转人工客服或返回标准错误提示。

一句话总结：永远不要相信概率模型能 100% 遵守规则。用代码的硬逻辑（Hard Logic）去包裹模型的软逻辑（Soft Logic）。

断层三：评估的量化——告别“体感测试”

这是最隐蔽、也最致命的断层。在 POC 阶段，评估通常是“凭感觉”（Vibe Check）。开发者测了 10 个 Case，觉得“挺聪明”，就通过了。

当你为了修复 Case A 修改了 Prompt，结果导致 Case B、C、D 全部崩坏时，你就会意识到“回归测试”的重要性。没有自动化评估体系的 Agent 项目，上线就是裸奔。

工程化解法：构建黄金数据集与自动化 Eval

在我的团队，没有通过 Eval 跑分的 Prompt 变更，禁止上线。

1. 建立黄金数据集（Golden Dataset）：收集 50-100 个真实的、覆盖各种边缘情况的“输入-输出”对。这是你的基准线。

2. 自动化评分：

   1. 确定性指标：JSON 格式是否正确？工具调用参数是否准确？（用代码断言判断）。

   2. 语义性指标：回答是否包含幻觉？语气是否得体？（用另一个高智商 LLM 作为 Judge 来打分）。

3. CI/CD 集成：每次 Prompt 或代码提交，自动跑一遍测试集。如果准确率从 95% 掉到 90%，构建失败。

一句话总结：软件工程里“无法度量就无法优化”的铁律，在 AI 时代依然有效。别相信你的直觉，相信数据。

尊重工程的复杂性

从 POC 到上线，本质上是一场“去魅”的过程。我们必须承认，目前的 LLM 依然是一个不稳定的推理引擎。Agent 工程化的核心，不是去追求模型有多聪明，而是通过架构设计、容错机制和评估体系，在一个不稳定的地基上，搭建出一座相对稳固的房子。

• 架构上，做减法，拆解巨型 Prompt。

• 流程上，做加法，引入状态机和强校验。

• 测试上，做乘法，用自动化矩阵覆盖人工盲区。

当你不再为 Agent 偶尔的一句“神回复”而沾沾自喜，开始为它如何处理一次“JSON 解析错误”而绞尽脑汁时，恭喜你，你终于跨过了那个断层，进入了真正的 Agent 工程化世界。