AI Agent 应用开发最容易走偏的地方，是先做一个聊天框，再去想它能做什么。聊天框演示很容易，但进入真实业务后，问题会变得具体：它能看哪些资料，能不能改数据，错了谁负责，什么时候必须让人确认。
所以 Agent 的第一步不是选模型，而是定边界。边界定清楚，模型、知识库、工具调用和验收才有落点。
先选一个具体任务
不要从宽泛概念开始。先选一个具体任务，比如整理客户提交的信息，给工单分类，检索制度并生成回复草稿，或者检查合同字段是否缺失。
任务越具体，输入、输出和失败分支越容易写清。一个能稳定完成窄任务的 Agent，比一个什么都能聊但不可控的助手更适合上线。
资料来源要能追溯
企业知识库不是把所有文档上传。资料要有来源、更新时间、适用范围和权限。旧制度、临时说明、销售话术、合同条款混在一起，Agent 就很难判断该引用哪一份。
涉及对外回复、价格、合同、售后政策时，最好让 Agent 输出引用来源。人能看到它根据哪段资料生成结论，才方便审核。
工具调用要分级
Agent 只回答问题，风险还算可控。一旦它能调用工具，就要给工具分级。查询数据、创建工单、修改状态、发送邮件，影响完全不同。
- 低风险动作：检索、总结、生成草稿。
- 中风险动作：创建记录、打标签、发送内部提醒。
- 高风险动作：修改关键数据、对外发送正式结论、触发付款或合同流程。
高风险动作不要自动执行。让 Agent 先给出建议和理由，人工确认后再继续。
人工确认不是拖慢效率
很多 AI 应用上线失败，不是因为模型不够聪明，而是流程里没有人工确认点。结果一旦出错，没人知道它为什么这么做，也没人知道应该从哪里改。
人工确认可以放在关键位置：对外发送前、修改数据前、触发通知前、遇到低置信度或资料冲突时。这样做能让 AI 进入流程，同时保留控制权。
评测样例要来自真实业务
上线前要准备正常问题、边界问题、错误输入、缺资料问题和权限外请求。每次改知识库、提示词或工具调用，都用这批样例回归。
评测不需要一开始很复杂，但必须具体。比如“客户问退换货政策”不如“客户购买 32 天后要求退货，订单来自某渠道，应该怎么回复”有价值。
日志决定后续能不能改
Agent 的输入、检索片段、工具调用、人工确认和最终输出，都应该留下记录。没有日志，出了问题只能猜。
AI Agent 应用开发真正要解决的不是“能不能回答”，而是“能不能在真实流程里可控地工作”。这也是它和普通聊天机器人的分界。
不要把提示词当成全部方案
提示词很重要，但企业 AI Agent 不能只靠提示词维持稳定。资料来源、工具权限、输出格式、人工确认、异常处理和日志记录，都会影响上线后的可用性。
如果一个 Agent 只能靠不断改提示词来修问题，说明系统边界还不够清楚。真正需要沉淀的，是任务定义和业务规则。
高风险场景要先做半自动
涉及对外正式回复、合同条款、价格政策、付款、客户资料修改等动作，第一版更适合半自动。Agent 负责检索、整理、生成建议，人负责确认和发送。
这样不是保守，而是让系统能进入真实业务。等日志里看到它在某些任务上长期稳定，再逐步放开自动化范围。
上线后要有人看日志
AI Agent 应用上线以后，不能只看调用量。要看哪些问题答得稳定，哪些问题总是需要人工改，哪些资料经常被引用，哪些工具调用失败。
这些日志会反过来指导知识库整理、提示词调整和流程改造。没有人看日志，Agent 很快会变成一个没人敢负责的黑盒。
评估时要同时看成本
AI Agent 不是只看调用模型的费用。真正的成本还包括资料整理、接口开发、人工审核、日志存储、评测维护和后续改流程。早期如果只算接口调用费，很容易低估项目。
因此第一版要小。选一个有明确收益的环节，先看它能不能减少重复整理、减少查资料时间，或者让流程更容易追踪。
什么时候暂时不开发
如果资料没有负责人、流程经常变化、系统没有接口、风险动作没人审核，暂时不要急着开发 Agent。先做知识整理、权限梳理或内部工具，往往更有效。
AI Agent 应用开发不是把 AI 放到每个入口。它要接住一段真实任务，并且出错时能被人发现、记录和修正。
