01 · 先避坑
不要把第一个 Agent 做成万能助手
很多企业一想到 Agent，就想做一个“什么都能问、什么都能做”的公司级助手。这个方向听起来很有想象力，但非常不适合作为第一步。因为知识范围太宽、权限太复杂、用户预期太分散，最后往往变成一个回答不稳定、没人敢把关键工作交给它的工具。
更合理的做法，是把 Agent 定义成一个具体角色：投研资料助理、客户材料整理员、制度问答助手、审批预审员、项目秘书、售后知识助手。角色越清楚，知识源、工具权限、输出格式和验收标准越容易设计。
02 · 高频场景
六类最适合先做的企业 Agent 场景
判断一个场景是否适合 Agent，可以先看它是不是需要连续做几步：读取资料、理解规则、生成中间结果、调用工具、提醒负责人、等待人工确认。如果只是一次性问答，普通知识库可能就够了；如果涉及多步骤处理，Agent 的价值会更明显。
从企业落地经验看，下面六类场景最适合作为第一批试点，因为它们重复性高、价值容易解释、风险也相对可控。
- 资料整理 Agent：自动整理会议纪要、客户资料、行业动态、项目材料。
- 知识问答 Agent：基于制度、手册、SOP、项目文档回答问题并引用来源。
- 监控预警 Agent：定时追踪政策、公告、舆情、竞品、客户动态并推送摘要。
- 审批预审 Agent：提前检查合同、报销、采购、授信材料中的缺失项和风险点。
- 报告生成 Agent：按模板生成周报、经营分析、投研晨报、项目简报初稿。
- 客户跟进 Agent：汇总客户历史互动，生成拜访准备、跟进建议和待办提醒。
03 · 验收标准
一个场景适不适合 Agent，要看能不能被验收
很多 Agent 项目失败，不是因为模型不会回答，而是因为需求无法验收。业务方说“希望更智能”，技术方交付一个聊天入口，最后双方都不知道好不好用。企业场景必须先定义验收标准。
验收标准可以很具体：摘要是否覆盖关键要点，引用来源是否准确，风险点是否漏掉，输出格式是否符合模板，通知是否发给正确负责人，处理时间是否明显缩短。只要这些指标无法定义，项目就不适合立刻开发。
- 输入是否稳定：文件、表单、消息、表格或接口是否清楚？
- 输出是否标准：摘要、清单、判断、报告、提醒是否有模板？
- 边界是否明确：Agent 能做什么，不能做什么？
- 人工确认点是否清楚：哪些动作必须人点确认？
- 失败兜底是否存在：Agent 错了，能否退回人工流程？
04 · 试点路径
用 2-4 周做出首版 Agent，而不是等半年平台
企业第一个 Agent 最重要的是让真实用户用起来。首版可以很小：只接一个知识库，只服务一个团队，只处理一种任务，只做有限工具调用。小不代表价值小，关键是能跑在真实流程里。
首版上线后要看三类数据：用户是否愿意每天使用，Agent 输出是否被采纳，人工复核发现的错误是否可修正。只要这三件事成立，就可以逐步扩大知识范围、接入更多工具和流程。
- 先画流程：触发条件、输入资料、处理步骤、输出物、确认点。
- 再接资料：只接最必要的文档、表格或系统接口。
- 然后小范围试用：让 5-10 个真实用户连续用两周。
- 最后看日志迭代：根据失败问题调整知识、提示词和工具权限。