智能体从“能回答”走向“能办事”，关键不在增加提示词，而在建立安全、清晰、可审计的系统连接。
一、把业务能力包装成可调用工具
智能体不应直接操作数据库或模拟页面点击，而应通过受控接口调用查询、计算、提交和通知等能力。每项工具需要清楚说明用途、输入、输出和权限。
工具粒度不能过粗，否则一次调用影响范围难以控制；也不能过细，否则模型需要编排过多步骤。
二、身份和权限必须贯穿调用链
智能体代表用户行动时，应继承用户身份并执行最小权限控制。模型能够想到某项操作，并不意味着当前用户有权执行。
系统应在工具层再次校验，而不是只依靠前端登录状态或提示词说明。
三、区分查询、建议与执行
查询通常风险较低，建议不会直接改变业务状态，执行则可能产生正式记录。三类能力应采用不同的控制策略。
涉及付款、审批、发布或删除的操作，适合先展示即将执行的内容和影响范围，由用户确认后再提交。
四、用任务状态管理长流程
跨系统任务可能持续较长时间，并遇到等待审批、接口超时或数据补充。智能体需要保存步骤状态、输入依据和已完成动作。
状态管理使任务能够暂停后恢复，也让人工接管时可以理解之前发生了什么。
五、建立异常与回退机制
接口失败不应简单触发无限重试。系统需要区分临时故障、参数错误、权限不足和业务拒绝，并采用不同处理方式。
对于已经执行的部分动作，应预先设计补偿或撤回方式；无法自动回退时，及时转交人工。
六、分阶段建设企业级智能体
第一阶段可以从只读查询和内容辅助开始，验证知识与交互；第二阶段接入低风险工具；第三阶段再扩展跨系统流程和有限自主执行。
每个阶段都应以任务完成率、人工接管率、错误类型和业务效果评估，而不是只看对话是否自然。
连接现有系统有三种常见方式
第一种是只读查询，智能体通过受控接口读取客户、订单或经营数据，适合信息汇总和辅助分析。第二种是业务准备，智能体完成材料整理和参数建议，再由用户在原系统确认提交。第三种是受控执行，智能体直接调用业务接口改变状态，但必须经过权限校验、风险判断和必要的人工确认。
在智能体与老系统之间增加适配层
许多现有系统接口颗粒度不一致，参数名称也带有历史技术含义。直接把底层接口开放给模型，会增加理解错误和误操作风险。适配层可以把技术接口包装成业务含义明确的工具，例如“查询合同状态”“创建待审核申请”，并限制参数范围和返回内容。
身份和权限必须贯穿调用链
智能体代表谁执行，是系统连接中最重要的问题。工具调用应携带真实用户身份，由目标系统进行最终授权，不能让智能体共享一个高权限公共账号。对于跨系统任务，还需要统一记录每一步由谁发起、使用什么权限以及改变了什么状态。
不要忽略事务和异常处理
一个任务可能先在系统甲创建记录，再在系统乙提交申请。如果第二步失败，第一步如何撤销或转人工，需要提前设计。智能体可以规划动作，但跨系统一致性仍要由可靠的业务机制保障。