我叫顾砚舟，做企业数字化产品与AI应用落地这几年，最常见的场面不是“要不要上AI”，而是会议室里一圈人盯着同一个问题：智能体技术到底能解决什么，怎么落到KPI上，出了事谁兜底。
我下面这份指南，按我在项目里踩过的坑来写：怎么判断适不适合、怎么选型、怎么上线、上线后怎么管。你不需要先把概念背熟，照着做也能落地。
我通常先把需求按三道闸门过滤，不通过就不建议上智能体技术。
闸门一：任务能不能被“验收”智能体适合有明确验收标准的工作：输出格式、字段完整性、命中率阈值、可抽检的依据链。例如“把客服工单归类并生成可回溯的处理建议”可以验收；“帮我想一个更打动人心的品牌策略”则更像创意协作，适合助手，不太适合自治执行的智能体。
闸门二：流程里有没有“工具动作”智能体的价值在于调用工具：查询知识库、读写CRM、生成工单、触发RPA、跑SQL、发邮件、开票、拉取物流状态。如果你的场景只是对话问答，常规RAG（检索增强）+权限控制可能就够；一旦出现“要做事”，智能体才开始有意义。
闸门三：失败成本能不能被管住我会把失败成本分成三类：
- 低成本：写摘要、做初稿、生成检查清单
- 中成本：自动创建工单、更新字段、发提醒
- 高成本：对外发送报价、改合同条款、触发财务支付高成本场景可以做，但要把“人类确认点”设计进流程里，把权限、日志、回滚、双人复核当成标配，而不是后补丁。
市场上方案很多：自研框架、云厂商智能体平台、开源编排框架叠加企业能力。选型别被演示视频带跑，我会盯住四件事。
1）身份与权限：能不能做到“最小可用权限”智能体的“手”是工具接口，最危险的不是模型胡说，而是它真的能改数据、发消息、开权限。我会要求：
- 工具级别权限（按动作、按数据范围、按环境）
- 临时令牌与到期机制
- 关键动作强制二次确认或人工审批这一点往往比模型参数重要得多。
2）可观测性：每一步有没有日志、能不能复盘上线后最磨人的问题是：“它为什么这么做？”可落地的智能体系统至少要有：
- 计划/步骤记录（它打算做什么）
- 工具调用记录（调用了谁、参数是什么、返回是什么）
- 成本与耗时（token、API次数、外部依赖耗时）没有这些，运维和合规会把你拖死。
3）知识与数据：RAG不是装饰品，是地基业务场景里，智能体经常需要“按公司规则办事”。我会把知识分层：
- 稳定规则：制度、SOP、合同模板条款
- 动态信息：库存、价格、排班、客户状态
- 项目资料：历史工单、邮件往来、会议纪要动态信息尽量走系统接口实时取数，别把它“灌进向量库当真相”，否则一更新就全错。
4）安全与合规：数据到底去哪儿了如果涉及客户隐私、商业机密、源代码，我会在合同与技术方案里明确：
- 数据是否用于训练、是否可选择退出（opt-out）
- 存储位置与保留周期
- 传输加密与审计能力这类条款往往在云厂商文档里写得很细，你要做的是把它落实到项目配置和流程上，而不是“口头承诺”。
智能体技术落地最怕一步到位。我更推崇从半自动开始，让业务接受、让风险可控。
1）把任务拆成三段：理解—行动—交付以“销售跟进智能体”为例，我会这样拆：
- 理解：读客户信息、识别阶段、提炼关键异议
- 行动：查询产品知识库、拉取价格政策、生成跟进计划、创建CRM任务
- 交付：输出给销售一份可编辑的邮件/话术+CRM已建任务+下次提醒拆开之后，你会发现最该自动化的不是“写话术”，而是“把该建的任务建好、该拉的数据拉齐”。
2）把“人类确认点”放在刀刃上我通常把确认点放在两类节点：
- 对外动作：发邮件、发报价、对外承诺交期
- 写入核心系统：改客户等级、改合同字段、触发发票或支付确认点不是为了拖慢，而是为了把责任边界讲清楚：智能体给建议，业务负责拍板。
3）用小样本验收，而不是用“感觉不错”我更推荐用抽检与对照来验收：
- 抽取固定批次工单，比较“人工处理耗时/正确性”与“智能体辅助耗时/正确性”
- 设定不可触碰的红线：例如“不得编造政策条款出处”“不得跳过审批流写入财务系统”验收不需要华丽指标，但要能复盘：错在哪里、为什么错、怎么改提示词/工具/数据。
4）上线后要“管住它”：版本、回滚、降级智能体系统一旦连上业务工具，就不再是一个聊天窗口，而是“会动的系统”。我会要求：
- Prompt、工具、知识库都有版本号
- 一键降级到“只读+建议模式”
- 失败兜底策略：工具超时怎么办、接口返回空怎么办、权限不足怎么办这套治理做得好，业务才敢把更关键的流程交给它。
坑一：把“生成内容”当成“完成任务”智能体写一段“已处理完毕”的总结很容易，但是否真的建了工单、更新了字段、通知了相关人，这些要靠工具动作与日志验证。我的做法是让交付物尽量结构化：带工单号、带更新字段、带时间戳、带引用来源链接。
坑二：工具太多导致“计划失控”工具不是越多越好。工具越多，选择空间越大，越容易走偏。我会把工具按业务角色收口：客服智能体只给客服相关的3-6个工具；财务智能体只给财务域工具。能用一个“聚合接口”解决的，就别暴露十几个细碎API。
坑三：把知识库当万能答案，忽略实时数据价格、库存、交期、账号状态这类信息必须走实时查询。否则你会遇到最尴尬的投诉：智能体引用了“旧政策”，还说得头头是道。能实时取数的，别让它凭记忆。
到2026年，行业里对智能体的关注点明显从“能不能跑起来”转向“能不能被治理”。一些可参考的公开材料里，已经把风险管理、透明度与可控性写得更具体：
- NIST 在其 AI 风险管理框架相关资源中持续强调可治理、可测量与可追责的实践路径（来源：nist.gov）
- ISO/IEC 发布的 AI 管理体系标准为组织层面的治理与流程化管理提供了参考（来源：iso.org）
- OWASP 针对大模型应用的安全风险与防护思路形成了更清晰的清单化建议（来源：owasp.org）
我不建议你把这些当“合规作业”，更应该把它们当工程清单：把权限、日志、评测、红线、回滚写进项目里，智能体才可能长期跑。
智能体技术真正的门槛，不在于你能不能做出一个会说话的Demo，而在于你能不能把它放进业务系统后，依然可控、可追责、可迭代。我做项目时最喜欢的交付状态，是业务同事敢用、敢依赖、也敢按下暂停键——这才是上线的开始。
