Agent 与聊天助手的分界，在于它能不能动系统
只做问答时，模型输出通常停留在屏幕上。接入搜索、文件、工单、邮件或业务接口以后，一句话可能变成一次真实操作：读取客户记录、创建任务、修改状态，甚至把内容发给外部人员。此时，提示词写得再周全，也不能替代账号权限和业务规则。
2025 年春季，主流模型平台陆续把网页搜索、文件检索、计算机操作和工作流编排放进 Agent 开发工具。能力变多后，企业更需要先回答四个问题：Agent 代表谁工作，能看到什么，允许做什么，做错以后怎样停下并恢复。这四个答案应写进系统，而不是留给模型临场判断。
把每项工具拆成可读、可写和可承诺的动作
同一个业务系统里，不同动作的风险差别很大。查询订单状态通常是读取；创建售后工单已经产生写入；修改价格、发送合同或承诺交期则会影响客户权益。项目开始时可以按动作逐项列清输入、输出、调用身份和影响范围，再决定哪些动作可以自动完成。
工具接口最好窄一些。与其给 Agent 一个覆盖整套 CRM 的通用入口，不如提供查询客户、创建待办、提交草稿等边界清楚的接口。参数由服务端校验，租户、角色和数据范围沿用原系统权限。模型只能提出调用请求，最终能不能执行，由接口和账号决定。
人工确认要放在会产生后果的位置
并非每一步都需要弹窗确认。频繁打断会让使用者疲惫，最后只剩下机械点击。确认节点应放在不可轻易撤销、涉及对外发送、改变金额或权限、处理敏感信息的位置。确认页面要给人足够上下文，包括数据来源、拟执行动作、关键参数和可能影响。
草稿与正式动作也应分开。Agent 可以整理回复、填写报价模板或准备审批材料，但真正发送、盖章、付款和授权仍由指定人员完成。这样既保留了自动整理的效率，也让责任落在清楚的业务角色上。
留痕不是保存一段聊天记录
排查一次 Agent 失败，需要看到它当时使用了哪些资料、选择了什么工具、传入哪些参数、接口返回什么，以及哪位人员作过确认。只有最终对话，很难判断问题来自模型、检索、权限、接口还是业务规则。运行记录应按任务串起这些步骤，并对敏感字段做必要脱敏。
记录也要控制范围。企业不必为了审计无限期保存所有原始内容。可以按任务风险设置保存期限和访问角色，把调试数据与正式业务记录分开。涉及个人信息时，还要说明处理目的、访问范围和删除方式。
失败时先停止扩散，再考虑自动恢复
工具超时、接口返回空值、知识版本冲突和权限变化都很常见。Agent 遇到不确定结果时，不应自行补写成功状态，更不能反复重试一个可能产生重复写入的动作。接口需要幂等标识，任务需要明确的失败状态，超过重试条件后转给人工。
自动恢复适合可验证、可撤销的步骤，例如重新读取资料或刷新查询。涉及写入的恢复要谨慎：先检查上一次是否已经生效，再决定继续、回滚还是等待处理。把这些分支写进工作流，远比在提示词里要求“务必谨慎”可靠。
上线前用真实任务检查 Agent 的边界
测试不应只看十个成功案例。还要加入缺字段、旧版本资料、同名客户、无权限账号、接口中断和恶意指令，观察系统会不会越权或在证据不足时继续行动。每个样本都要写明可接受结果和不能出现的后果。
首批上线可以只开放一项任务和少量使用者，保留人工复核。运行一段时间后，再看工具成功率、人工接管原因、重复操作和撤销情况。任务边界稳定以后再扩展工具，比一开始追求“全能 Agent”更容易维护。