从 0 到 1 上线一个智能体产品

一个完整的落地流程

前面的课程分别讲了智能体原理、无代码平台、开发框架与 MCP。这一篇把它们串成一条从 0 到 1 的完整路径。以下六步不是瀑布式执行，而是不断回环迭代——但每一步都有明确的产出物，可以检查、可以评审。

第一步：需求定义

回答三个问题，并写成一段话：

• 服务谁：目标用户与使用场景（内部员工？C 端用户？）；
• 完成什么任务：具体到「查订单状态、解释退款政策」这个颗粒度，而不是「智能客服」四个字；
• 成功标准：用什么指标证明它值得上线——任务解决率、转人工率、用户满意度？

产品决策提示：智能体项目最常见的死因是需求定义为「一个什么都能问的助手」。任务定义得越窄，上线越快、效果越好。先做一个窄而深的智能体，再逐步扩展边界——顺序反了就是无底洞。

第二步：能力边界

明确「做什么」，更要明确「不做什么」：哪些问题必须转人工？哪些操作禁止执行？把边界写进系统提示词与产品交互（如高风险操作强制弹窗确认），并设计好超界时的兜底话术。边界不清的智能体，上线后就是事故的来源。

第三步：技术路线选择

路线	适合	优点	代价
无代码（Coze / Dify）	标准场景、快速验证	天级上线、无需工程投入	深度定制受限、规模化成本高
框架（LangGraph 等）	复杂流程、嵌入自有产品	完全可控、可调试可观测	需要持续工程投入
直接调 API	极简场景、AI 原生产品	最轻、无平台依赖	所有编排逻辑自己写

选择原则：用当下最轻的路线，满足当前阶段的目标。从无代码起步不丢人；需求被验证、瓶颈出现后，再评估迁移。

第四步：Prompt 与工具设计

• 人设与规则：角色、语气、边界、兜底话术，全部写进系统提示词；
• 知识库：确定知识来源、更新机制与责任人（详见 RAG 系列课程）；
• 工具清单：从任务反推（见 MCP 课程），每个工具写清触发描述与参数说明；
• 确认机制：高风险动作（对外发送、修改数据）设计人工确认环节。

第五步：测试评测

上线前至少做三类测试：

1. 功能测试：核心任务成功率，用真实用户问法（含错别字与口语）；
2. 边界测试：超界问题是否正确拒答与转人工，诱导性提问能否守住规则；
3. 回归评测：积累一组「标准问答对」作为评测集，每次改提示词或换模型后全量跑一遍，防止按下葫芦浮起瓢。

评测集就是智能体产品的「自动化测试用例」，要从第一天开始积累。

第六步：上线与监控

上线不是终点。持续监控四类指标：

• 质量：任务成功率、用户点踩率、转人工率；
• 成本：token 消耗与单次对话成本；
• 安全：超界回答、工具误调用、投诉；
• 知识时效：知识库内容是否过期。

建立周期复盘机制（如每周过一次 Bad Case 清单），把问题归类到提示词、知识库、工具三个桶里分别修复。

上线 Checklist（可复用）

• 需求一句话定义与成功指标已确认
• 能力边界与转人工规则已写入提示词
• 高风险操作有人工确认机制
• 核心任务评测通过，回归评测集已建立
• 边界与诱导性提问测试通过
• 监控指标与告警已配置
• 知识库更新责任人与频率已明确
• 降级方案（如退化为关键词 FAQ）已就绪

本节要点

• 六步流程：需求定义 → 能力边界 → 技术路线 → Prompt 与工具 → 测试评测 → 上线监控，每步都有可检查的产出物。
• 任务定义越窄上线越快，「什么都能问的助手」是智能体项目的头号死因。
• 技术路线选当下最轻的：无代码验证、框架扩展、API 极简，不要提前工程化。
• 回归评测集是智能体的自动化测试，从第一天积累，每次改动全量重跑。
• 上线后盯质量、成本、安全、知识时效四类指标，Bad Case 按周复盘、按桶修复。