Demo

在 Agent 中，‌Demo‌是 ‌Demonstration（演示版）‌ 的缩写，指为展示 Agent 核心能力（如规划、工具调用、多轮交互）而构建的‌非生产级原型系统‌，通常仅验证逻辑可行性，缺乏稳定性、安全护栏及持久化等工程支撑 。‌‌

Demo的核心作用是‌快速验证技术可行性、向相关方直观展示能力，是Agent从概念走向落地的第一步‌。

通常一个Demo只需要证明：

• 模型能理解任务
• 工具链能接通
• 系统能完成一个示例流程

核心特征与局限

• ‌目的单一‌：用于快速验证“模型能否在理想环境下完成任务”，侧重展示上限而非保证下限 。
• ‌环境简化‌：运行在受控本地或测试环境，无真实数据压力、无并发冲突、无异常熔断机制 。
• ‌功能残缺‌：通常缺失持久化记忆、检查点恢复、权限校验、成本监控、人工干预（HITL）及可观测性链路 。
• ‌风险掩盖‌：往往忽略长任务中的死循环、工具误调、Token 溢出及幻觉累积等生产级隐患 。‌‌
• 只能证明“有可能可行”，不能证明“长期可行”。

---

为什么Agent Demo一落地就不稳定

真正的系统关心的是“会不会坏”

此时需要关注的问题变成：

• 用户输入是否稳定
• 外部数据是否可靠
• 工具是否会失败
• 系统是否会重复做无效动作
• 出错后能不能恢复
• 成本和延迟是否能接受

---

常见断层1：目标定义太模糊

• 系统不知道什么时候结束
• 探索范围不断膨胀
• 输出标准不稳定

从Demo到生产，第一步通常不是“换更强模型”，而是“把目标写窄”。

常见断层2：状态没有设计

多数情况下Demo只是把所有信息塞进Prompt，然后不断续写，这样会导致：

• 中间结果没有结构化保存
• 系统会忘记已经做过什么
• 同一个工具被重复调用
• 执行中断后无法恢复

常见断层3：工具调用被过度乐观地看待

Demo中默认工具一定可用、返回格式稳定、延迟可接受、没有权限问题

而真是情况往往是：API会超时、数据格式会变、权限会失败、返回结果会为空或部分缺失

常见断层4：误认为“会思考”=“会执行”

• 得到的结果无依据，证据不充分
• 任务未达到标准却认为已完成

生产系统不能只看最终文本，需要清楚执行过程，所用数据以及每一个结果的依据

常见断层5：没有结束条件和预算控制

进入循环后不断尝试导致成本失控、延迟失控最终用户体验崩掉

一个可用的Agent必须有预算和边界

常见断层6：没有可观测性

只能看到结果而没有中间任何步骤，这将导致几乎无法维护。

很多Agent框架都会补tracing、logging、checkpoint这些能力

至少应该看到每一轮的状态、每一步决定、每次工作调用、错误原因、最终退出条件

---

综上：如果要把Demo向真实系统推进，顺序最好是：

1. 先把目标缩窄
2. 明确状态结构
3. 给工具调用加异常处理
4. 定义结束条件和预算上限
5. 增加日志、追踪和人工接管点

避免选择：更换更强模型、堆更多的Prompt希望系统自己变稳定