表格较宽时，可以用键盘方向键或触控手势横向滚动查看完整内容。
直接答案
企业做 AI Agent，至少要准备真实任务样本、可用知识资料、业务规则、系统字段与接口、用户权限、异常处理方式和一组可验收的预期结果。
Agent 要执行任务，而不只是回答问题。只有文档，没有动作规则和系统边界，最多做出一个演示型聊天入口。
七类需要准备的数据
- 真实任务样本：过去处理过的订单、工单、邮件或审批，先脱敏；
- 输入材料：每次任务会收到哪些字段、附件和上下文；
- 标准依据：制度、产品资料、模板、价格规则及有效版本；
- 动作流程：先判断什么、调用哪个系统、由谁确认；
- 权限规则：哪些用户能读、写、审批和对外发送；
- 异常样本：缺字段、冲突、重复、接口失败和高风险情况；
- 验收结果：对每个测试样本说明正确输出及允许误差。
数据不是越多越好
第一期更需要“小而干净”的样本集。混入过期资料、重复记录和无法解释的历史结果，会让团队无法判断错误来自模型、规则还是数据。
建议先选 30—50 个真实任务，覆盖常见情况和重要异常。每条记录都保留来源、处理人、结果和是否可用于测试，敏感信息应在进入开发环境前脱敏。
接口数据要先做验证
如果 Agent 需要连接 CRM、ERP、工单或邮件系统，应先确认接口文档、测试账号、字段含义、调用限制和写入权限。能读取数据不代表可以安全执行动作；金额、删除、审批和对外发送应默认保留人工确认。
一张准备度检查表
| 检查项 | 可以进入试点的状态 |
|---|---|
| 任务范围 | 一句话说清输入、动作和输出 |
| 样本 | 有 30—50 条脱敏真实记录 |
| 规则 | 负责人能解释常见与异常处理 |
| 系统 | 接口、账号和测试环境可用 |
| 权限 | 读写与确认责任有明确边界 |
| 验收 | 每条测试任务有预期结果 |
如果其中多数为空，先做业务盘点而不是选模型。可以结合中小企业做 AI Agent 从哪里开始选择一个低风险任务，再逐步补齐数据和权限。
把问题放进真实业务里
以下情境用于决策演练，不是虚构客户成果：选择一个具体任务，例如整理售后工单。除知识文档外，还要准备真实输入、正确结果、缺字段样本、权限矩阵和系统测试账号。把三十条正常样本和二十条异常样本分开，才能知道 Agent 是“会演示”还是“能工作”。
开会时不要只谈观点
把下面五项填完，再决定采购、开发或优化动作：
- 输入字段和附件：__________
- 规则的有效版本：__________
- 正确输出样例：__________
- 异常与回退方式：__________
- 读写审批权限：__________
最容易踩的坑
把所有历史资料一次性导入。过期制度、重复文件和互相冲突的答案会让错误难以定位，也可能扩大敏感信息暴露面。
什么时候才适合进入下一步
每条测试任务都有来源、预期结果、允许误差和责任人；敏感数据已脱敏，写操作默认需要确认。
如果这些信息还无法写清，合理动作不是马上采购工具或签开发合同，而是先补一轮访谈、样本和责任确认。这样做看起来慢半步，通常能减少后面的返工，也让供应商给出的范围、报价和验收更可比较。
复盘时再追问一层
不要在会议结束时只留下“原则同意”。请指定一名负责人，用最近发生的一笔业务验证“输入字段和附件”和“规则的有效版本”是否有记录，再让另一名实际执行者检查“正确输出样例”是否符合现场情况。最后，把“异常与回退方式”与“读写审批权限”写成可以在下一次评审中核对的证据，而不是写成“后续优化”。如果两个人对同一项的答案不同，应先解决定义和责任分歧；这类分歧进入系统后，只会变成更难修改的权限、数据或流程问题。