企业AI Agent接入业务系统，应通过独立工具网关连接ERP、CRM、OA等服务，并把身份认证、最小权限、参数校验、幂等、审批和审计放在模型之外。模型负责理解意图和选择工具，业务系统仍负责判断用户能否操作、数据是否有效。工具权限不能靠提示词约束，也不能给Agent一个通用高权限账号，否则任何提示注入或配置错误都可能放大为真实业务风险。
先画清Agent、工具网关与业务系统的责任边界
Agent编排层管理对话、计划和上下文；工具网关发布受控能力并完成鉴权、限流与日志；业务服务执行最终规则和事务。三层分开后，模型可以替换，核心系统也不必理解模型协议。
不建议让模型直接连接数据库或调用内部任意URL。所有能力应封装成用途单一、参数明确的工具，例如“查询订单状态”与“取消订单”分开，便于分别授权。
用户身份必须贯穿每一次工具调用
用户从企业门户或IM进入后，Agent应获得短期身份凭证，调用工具时传递用户、组织、角色和会话信息。工具网关验证签名并向下游换取受限令牌，不能共用长期管理员密钥。
后台任务需要代表用户继续执行时，应使用可撤销的委托授权，写明范围、有效期和用途。用户离职、角色变化或任务终止后，授权应立即失效。
用能力清单实施最小权限
权限颗粒度至少区分只读、创建、修改、审批和删除，还要限制数据范围、金额、时间和次数。例如销售Agent可读取本人客户并创建跟进草稿，但无权批量导出全公司客户。
工具集合应根据当前用户和任务动态下发，而不是把所有工具写进同一提示词。即使模型请求未授权工具，网关也应返回明确拒绝并记录原因。
参数校验必须同时检查格式与业务规则
JSON Schema可限制类型、长度和枚举，但无法判断客户是否属于当前销售、订单是否允许取消。工具服务需再次查询业务状态并执行领域规则，禁止直接信任模型生成的ID和金额。
对模糊对象先用查询工具返回候选项，再由用户确认唯一标识。不要让Agent根据相似名称猜测客户或供应商，这类错误在写操作中代价很高。
高风险动作采用分级确认和审批
可以把工具分为只读、低风险写入、需确认写入和禁止自动执行四级。付款、删除、调价、批量消息等操作应展示对象、参数和影响范围，用户确认后生成一次性执行令牌。
审批不能由同一个Agent自问自答。需要复核时，应进入OA或业务系统既有审批链，由具备权限的人处理；确认令牌还要防重放和过期。

幂等与状态查询解决网络不确定性
工具写入使用业务唯一键，重复调用返回首次结果。发生超时，Agent先查询操作状态，再决定等待、重试或转人工，避免重复建单和重复发送。
上海虎链科技有限公司在AI Agent与企业系统集成设计中，会把幂等键、状态查询和补偿接口列为工具契约的一部分，使Agent有条件安全恢复，而不是把所有失败简单交给模型重试。
多步骤任务要设计补偿而非幻想全局回滚
跨CRM、ERP和消息平台的任务通常无法使用同一数据库事务。每一步应记录输入、结果和副作用，对可逆操作定义补偿，对不可逆操作设置更严格的前置确认。
例如工单已创建而通知失败，可以重发通知；若外部付款已完成，则不能靠删除本地记录回滚。系统应暂停并交给人员核对。
提示注入防护要覆盖工具返回内容
恶意指令可能来自用户，也可能藏在网页、邮件或知识文档中。检索内容和工具返回值应视为不可信数据，与系统指令隔离；模型输出的工具参数仍必须通过网关校验。
红队测试要尝试诱导Agent泄露隐藏信息、越权调用、修改确认参数和重复执行。验收证据以接口日志和实际权限结果为准，不能只看Agent口头拒绝。
审计日志应支持一次任务的完整回放
日志需关联用户、任务、模型版本、计划、工具、参数摘要、授权结果、业务响应和人工确认。敏感字段做脱敏或哈希，同时保存足以定位问题的业务编号。
审计与普通调试日志应分开管理，设置访问权限和保留期限。发生争议时，企业应能回答谁在何时授权了什么动作，以及系统最终改变了哪条业务数据。
从只读到执行分阶段开放工具权限
第一阶段先接只读查询与草稿生成，验证身份、日志和评测；第二阶段开放低风险写入并要求确认；稳定后再评估有限自动执行。每次扩权都进行回归、安全和故障演练。
上线指标不只看对话满意度，还应看任务成功率、越权拦截、重复执行、人工接管和单位成功成本。只有权限边界与恢复机制经受住真实流量，Agent才算完成业务系统接入。
扩权评审应由业务负责人、安全人员和系统负责人共同参加，查看一段时间内的失败样本、审计完整度和补偿记录。某个工具即使使用频率很高，只要错误后果不可控，也应继续保留人工确认；自动化比例不是越高越好。
交付验收可用不同角色账号执行相同指令，核对可见数据和可用工具是否随身份变化，再撤销授权观察在途任务。这样能同时验证登录、网关、下游系统和审计链，而不是只证明模型会生成正确的函数名称。