企业 AI Agent 系统落地需要哪些模块？
结论：生产级企业 AI Agent 不能只搭“模型、知识库、工具”三层。至少要完整覆盖身份入口、知识与数据、模型路由、工具权限、流程编排、安全控制、人工接管、可观测与评测；缺少权限、回退或审计，就只能算演示系统。
模块数量不是越多越好，关键是每项生产责任都有明确归属。模型负责理解和生成，业务系统提供事实与动作，程序控制权限和确定性规则，人员负责高风险审批与异常。把所有责任都塞进提示词，无法形成可靠边界。
在确定模型、数据与上线边界时，还可以对照 AI Agent 项目立项前如何验证效果可达性？ 和 我要做一个 AI Agent 应用，你们会帮我训练一个我的模型吗？；这些内容补充了需要放在同一项决策中考虑的上下文。
三种系统规模直接对比
| 建设级别 | 核心组成 | 可以上线做什么 | 缺失能力 | 结论 |
|---|---|---|---|---|
| 对话 Demo | 模型、提示词、简单前端 | 展示问答和生成效果 | 身份、权限、数据版本、监控和兜底 | 只用于验证交互 |
| 知识助手 | 身份、RAG、引用、反馈、日志 | 内部资料查询与辅助回答 | 通常不执行写操作，流程能力有限 | 多数企业首期范围 |
| 生产级 Agent | 知识、工具、编排、权限、审批、评测与运维 | 跨系统完成受控任务 | 开发、治理和持续运营成本最高 | 业务闭环明确后建设 |
八类能力分别解决什么问题
身份入口负责登录、组织、租户、角色和会话，让系统知道“谁在问”。知识与数据层处理文档解析、版本、元数据、检索和业务数据访问，保证答案能回到来源。模型路由层管理不同供应商或本地模型、embedding、上下文、缓存、限流和预算，不让业务代码绑死一个模型。
工具层把查订单、建工单、发通知等接口封装为有明确输入输出的能力。每个工具都要有服务身份、字段白名单、超时、重试、幂等、额度和审计，读写权限分开。流程编排层负责步骤、分支、状态、停止条件和失败补偿：确定性步骤尽量用代码，只有路径确实需要动态判断的部分才交给模型。
安全控制覆盖输入内容、敏感数据、提示词注入、输出校验、网络访问和密钥管理。不能假设模型会自觉遵守权限，也不能把检索到的文档视为可信指令。人工接管层提供审批、异常队列、原始证据和修改记录；退款、付款、删除、外发等高影响动作通常需要确认或双人复核。
可观测与评测层记录一次任务经过哪些模型和工具、耗时和成本、在哪一步失败、使用了哪些知识版本。开发阶段使用固定评测集和回归测试，上线后监控任务成功率、工具错误、人工接管和用户反馈。日志要保护个人信息和商业秘密，不能为了排错无限期保存完整对话。
模块应该自研还是采购
身份、核心业务规则和现有系统接口通常复用企业已有能力；基础模型、OCR、语音等可以按数据边界选择 API 或私有部署；向量库、工作流框架和观测平台则看团队维护能力。选型不能只看 Demo 功能，还要确认数据导出、模型切换、权限集成、故障恢复和退出成本。
实施顺序从一个端到端任务开始，而不是先建“大而全平台”。例如售后工单助手可以先完成登录、知识检索、只读查设备、生成工单草稿、人工确认和日志。这个闭环稳定后，再增加自动分派或更多工具。每新增一个工具，都重新评审权限和失败影响。
验收至少包括任务完成率、事实与引用准确率、工具调用成功率、重复写入次数、越权次数、人工接管率、P95 完成时间、单个成功任务成本和故障恢复时间。工具写操作还应做幂等、超时、并发和回滚测试；安全测试要覆盖恶意文档、间接提示词注入和越权参数。
滚水科技会围绕客户实际任务选择必要模块，并与现有 ERP、CRM、IoT 或内容平台集成。交付不应只有提示词和源代码，还应包括工具清单、权限矩阵、流程图、评测集、监控面板、部署配置、操作手册和回退方案。
参考依据
- OpenAI: A practical guide to building agents：用于核对模型、工具、指令、编排和 guardrail 等 Agent 基础组成。
- Anthropic: Building effective agents：用于比较工作流与自主 Agent，并说明从简单可组合模式开始的工程原则。
- OpenTelemetry GenAI Semantic Conventions：用于核对生成式 AI 调用、Agent 与工具的可观测语义；该规范仍在独立仓库中演进。
- OWASP Top 10 for Agentic Applications 2026：用于检查目标劫持、工具滥用、身份权限和自主执行风险。
不同业务不必部署同样多的产品组件，但身份、权限、失败处理、审计和评测这些责任不能省略。