Appearance
📦 企业 Agent 落地完整 SOP：从需求访谈到上线验收
📌 这篇不是给技术爱好者看的——是给真的接到了企业 Agent 项目、或者公司内部要推动 Agent 落地的人看的。写它的人接过、交付过、也踩过坑。
目标读者：接单开发者、企业内部推动 Agent 的工程师、想卖 Agent 项目的人。
01｜需求访谈：第一个小时决定项目生死
需求访谈问题清单
核心原则：客户说的"需求"通常不是真正的需求。他们说的是解决方案（"我要一个智能客服"），你要挖的是问题（"为什么现在的客服不行？"）。
□ Q1: 现在谁在做这件事？怎么做的？每天花多少时间？
（目的：量化当前的人力成本和效率基线）
□ Q2: 过去 6 个月，这件事出过什么错？最大的事故是什么？
（目的：找到业务的容错边界）
□ Q3: 这个问题如果不解决，会有什么后果？
（目的：判断这个项目到底重不重要。回答"也没什么" = 项目可以不做）
□ Q4: 谁是最终使用这个 Agent 的人？他们一天会用它多少次？
（目的：确定用户画像和使用频率）
□ Q5: 你的数据在哪里？什么格式？有多大？
（目的：提前暴露数据问题。80% 的 Agent 项目死在"数据没准备好"）
□ Q6: 如果 Agent 答错了，会发生什么？
（目的：确定容错成本——决定安全设计的级别）
□ Q7: 你期望的效果是什么？怎么算成功？
（目的：提前对齐验收标准。如果客户说不出，你就定标准）判断客户到底需不需要 Agent
不是所有问题都需要 Agent。问这三个问题判断：
1. 这个问题需要"理解语义"还是只需要"匹配规则"？
规则匹配 → 用传统规则引擎（更便宜、更可靠）
需要理解语义 → 考虑 Agent
2. 这个问题需要"多步推理"还是只需要"单次回答"？
单次回答 → 用 RAG（更简单、更可控）
多步推理 → 考虑 Agent
3. 这个问题容错成本高吗？
非常高（医疗、法律、金融核心交易）→ Agent 只做辅助，人做决策
较低（内部FAQ、内容辅助）→ Agent 可以直接回答02｜报价怎么拆：让客户看得懂
项目报价拆解表
不要报一个总价——拆开，让客户理解每一部分是什么。
| 阶段 | 交付物 | 工期 | 报价占比 | 客户需要做什么 |
| POC 验证 | 最小可行版本（50 case 评测集 + 基础架构） | 2-3 周 | 20% | 提供数据 + 安排 2-3 次需求对齐会 |
| MVP 开发 | 完整功能 + 评测体系 + Dashboard | 4-6 周 | 50% | 安排试用 + 收集反馈 |
| 上线部署 | 生产环境部署 + 灰度发布 + 运维 Runbook | 2 周 | 20% | 安排上线窗口 + 通知用户 |
| 维护期 | 3 个月维护（bugfix + Prompt 优化 + 月度报告） | 3 个月 | 10% | 持续提供反馈 |
定价区间参考（2026 年国内市场经验值）：
| 项目复杂度 | POC 价格 | 全项目价格 | 适合场景 |
|---|---|---|---|
| 简单 RAG（单数据源） | ¥8K-15K | ¥30K-60K | 内部知识库 |
| 中等 Agent（多工具） | ¥15K-30K | ¥60K-150K | 客服、数据分析 |
| 复杂 Multi-Agent | ¥30K-60K | ¥150K-350K | 全栈客服系统、企业级 Agent |
03｜技术方案模板
每个企业 Agent 项目必须包含的技术方案章节：
markdown
## 1. 系统架构
[图例建议：系统架构图——用户→路由→Agent→工具/RAG→LLM→输出]
## 2. 技术栈
- LLM: GPT-4o / Claude Sonnet / DeepSeek-V3（说明选型理由）
- 框架: LangGraph / CrewAI / AutoGen（说明选型理由）
- 向量库: Milvus / Qdrant / Pinecone
- 可观测: Langfuse / Custom Logger
- 部署: Docker / K8s / Serverless
## 3. 数据源梳理
- 数据源 1: [名称] · [格式] · [大小] · [更新频率]
- 数据源 2: ...
## 4. 安全设计
- 工具权限分级（L0-L3）
- HITL 机制
- Prompt Injection 防护
- 数据脱敏
## 5. 评测方案
- 评测集规模: 200+ case
- 评测方式: LLM-as-Judge + 人工抽样
- 通过标准: 输出层平均分 ≥ 4.0
## 6. 上线计划
- 灰度阶段: 内部 50 人 → 10% → 50% → 100%
- 监控指标: P95 延迟 / 错误率 / 费用 / 用户满意度
- 回滚方案04｜POC 怎么做：用最小的代价验证最大的风险
POC 目标不是"跑通"——是"找到项目中最大的风险并验证它"
POC 验收表：
□ 1. 数据能接入吗？
数据格式是否兼容？是否需要大量清洗？数据量是否足够？
□ 2. 核心场景能跑通吗？
选 3-5 个最核心的场景，人工评判 Agent 的回答质量
□ 3. 延迟能接受吗？
用户能接受 5 秒等待吗？如果 P95 > 10s，需要优化什么？
□ 4. 准确率有底线吗？
POC 阶段允许 70% 的准确率——这是正常的
□ 5. 客户方的数据/IT 配合度够吗？
如果客户说要 2 周才能提供数据——这 POC 已经失败了（不是技术问题）05｜验收指标怎么定
| 指标 | 测量方式 | 合格线 | 优秀线 |
| 自动解决率 | Agent 完整处理 / 总对话数 | ≥ 60% | ≥ 80% |
| 用户满意度 | 每次对话后评星（1-5） | ≥ 3.8 | ≥ 4.3 |
| P95 延迟 | Server 端计时 | ≤ 8s | ≤ 4s |
| 事实准确率 | 人工抽样 50 条打分 | ≥ 85% | ≥ 95% |
| 转人工率 | Agent 主动转人工 / 总对话数 | ≤ 30% | ≤ 15% |
06｜上线前 CheckList
□ 1. 评测集通过率 ≥ 90%
□ 2. 三层预算控制就绪（日/时/单次）
□ 3. 三层日志 + Dashboard + 告警 就绪
□ 4. 工具权限分级 + HITL 就绪
□ 5. 降级策略已测试（关掉一个 API，Agent 正确降级）
□ 6. 灰度发布就绪（1% → 10% → 50% → 100%）
□ 7. 回滚方案就绪（一键切回旧版）
□ 8. 安全审查通过
□ 9. On-call 排班 + Runbook 就绪
□ 10. 客户验收通过07｜后续运维和复盘
月度运维报告模板：
markdown
## 本月 Agent 运行报告
### 使用数据
- 总对话数: X
- 日均对话数: Y
- 自动解决率: Z%
### 质量数据
- 平均用户满意度: X/5
- 事实准确率（人工抽样）: Y%
- LLM-as-Judge 平均分: Z
### 成本数据
- 本月总费用: $X
- 平均每次对话费用: $Y
- 主要成本构成: LLM 调用 70% / 向量库 20% / 其他 10%
### 问题与改进
- 本月发现的问题: ...
- 已修复: ...
- 下月计划: ...08｜风险提示
⚠️ 接企业 Agent 项目的 5 个真实风险：
数据风险：客户说"我们有数据"，其实是一堆没整理过的散文件。合同里写明"数据交付时间"和"数据质量的最低标准"，否则项目可能延期 2-3 倍
期望风险：客户以为 Agent 是"魔法"——什么都懂、什么都能做。第一周就明确说清楚 Agent 的能力边界和容错率
范围蔓延：客户在 POC 之后开始加"顺便也做一个 XX 功能吧"。合同里明确 POC 之后新需求要重新报价
维护成本被低估：Agent 不是"上线就完了"——Prompt 要持续调、评测集要持续扩充、模型版本变更要做回归测试。维护期至少 3 个月，报价里必须包含
AI 依赖风险：你的 Agent 依赖 OpenAI / Anthropic 的 API——如果它们宕机或涨价，你的项目会受影响。合同里声明"第三方服务风险不在承包范围内"
🍋 本文为 AI Agent 学习路线 · 企业落地 SOP。© 2026 AI小柠檬。