1. 为什么“能聊天的 Agent”一进业务就废我见过太多团队在演示环境里把 Agent 调得风生水起问它一句“帮我查一下上个月的订单”它噼里啪啦调几个接口答案漂漂亮亮。可一旦把这套东西塞进真实业务流程问题立刻炸出来——它不知道“上个月”是自然月还是滚动 30 天不知道当前登录的人有没有权限看这批订单更不知道查完之后该把结果写回哪个工单系统。演示和落地之间隔着的不是模型能力而是上下文和权限这两道坎。先把话说透Agent 接进真实业务流程本质上是三件事的叠加——上下文注入、权限校验、动作执行。模型只负责“想”业务系统负责“给边界”和“兜底”。很多人一上来就纠结用哪个大模型、提示词怎么写其实方向就偏了。真实业务里模型换一个可能只是效果波动 10%但上下文给错了、权限放开了那是直接出生产事故的级别。这篇文章适合谁看如果你正在做企业内部助手、工单自动化、数据分析 Agent、客服辅助这类东西并且已经过了“跑通 Demo”的阶段正卡在“怎么让它真正干活”上那接下来的内容应该对你有用。我会按一个真实落地项目的推进顺序来讲先解决上下文怎么给再解决权限怎么卡然后是动作怎么安全执行最后是上线后怎么观测和迭代。全程用从业者的视角把每一步“为什么这么设计”讲清楚。需要提前说明的是下面涉及的具体系统名称、字段名、接口路径都是脱敏后的示意你在自己项目里要替换成真实的业务对象。但设计思路和踩坑点是通用的可以直接抄作业。2. 上下文注入别把整个数据库塞给模型2.1 上下文不是越多越好而是要“刚刚好”新手最容易犯的错是觉得模型上下文窗口大就把能拿到的数据全塞进去。我试过一个反面案例某次为了让它回答“这个客户最近怎么样”直接把客户近半年的所有交互记录、订单、工单全拼进提示词结果两万多 token 下去模型反而抓不住重点回答得又慢又泛。后来砍到只给最近 5 条关键交互加一个结构化摘要准确率立刻上来了。这里有个核心原则上下文的价值密度比总量重要。你要给模型的不是原始数据而是经过筛选和结构化的“决策所需最小信息集”。具体怎么筛我一般分三层会话层当前这轮对话的历史通常保留最近 3 到 5 轮就够再往前用摘要压缩。业务层跟当前任务直接相关的业务对象比如当前工单、当前客户、当前订单按需拉取。规则层这次任务要遵守的业务规则、话术规范、字段定义这部分相对固定可以做成模板。三层拼起来才是喂给模型的完整上下文。很多人只做了会话层业务层靠模型自己“猜”规则层干脆没有那 Agent 当然不靠谱。2.2 用“槽位”思路把模糊表达翻译成确定参数真实业务里用户说的话永远是模糊的。“帮我处理一下那个超时的单子”——哪个单子超时多久算超时处理是关闭还是转派这些都得在上下文注入阶段解决。我的做法是引入槽位填充机制。在把用户输入交给模型之前先用一轮轻量的意图识别加实体抽取把关键参数抠出来缺的再反问用户。举个具体例子用户说“查一下上周华东区的异常订单”我会先解析出槽位抽取结果来源时间范围上周需转成具体日期区间用户输入区域华东用户输入订单状态异常用户输入操作类型查询意图识别然后“上周”这种相对时间必须结合当前系统时间和业务日历转成绝对区间。这里有个坑不同业务对“上周”的定义不一样有的是周一到周日有的是滚动 7 天。这个规则必须写死在配置里不能让模型自由发挥否则同一个问题今天问和明天问答案不一致业务方直接不信任你。2.3 上下文窗口管理什么时候该压缩什么时候该丢弃长会话是上下文管理的重灾区。一个客服 Agent 跟用户聊了 20 轮前面聊的内容早就超出有效范围了。我的策略是滑动窗口加关键信息锚定保留最近 N 轮原文N 一般取 5。把更早的对话做一次摘要摘要里只保留“已确认的事实”和“未完成的动作”。关键业务对象比如工单号、客户 ID单独拎出来每轮都带上不参与压缩。这样既控制了 token 消耗又不会丢掉关键线索。实测下来一个原本要 8000 token 的会话压缩后稳定在 2500 左右响应速度提升明显而且因为噪声少了模型跑偏的概率也低了。提示压缩摘要这一步建议用便宜的小模型来做别用主力模型成本能省一大截。摘要质量只要保证事实不丢就行不需要文采。3. 权限校验Agent 不能比用户权限大3.1 最危险的设计用超级账号跑所有请求我见过一个真实事故某团队为了让 Agent 能查所有数据直接给它配了一个管理员账号。结果一个普通员工通过对话让 Agent 查到了他本不该看到的其他部门数据。这不是模型的问题是权限设计从根上就错了。铁律只有一条Agent 的权限必须等于当前发起用户的权限绝不能更大。实现方式有两种我强烈推荐第一种用户身份透传Agent 调业务接口时带上当前登录用户的身份凭证由业务系统自己做权限判断。Agent 只是个“代驾”方向盘还是用户的。权限预校验Agent 在规划动作前先调一个权限服务问“这个用户能不能做这件事”能才继续。第一种更彻底因为权限判断始终在业务系统内部Agent 绕不过去。第二种适合业务系统改造困难的情况但要注意预校验和实际执行之间可能有时间差得加二次校验。3.2 把权限判断前置到“规划阶段”很多人把权限校验放在动作执行前一刻这其实晚了。更好的做法是在 Agent 做任务规划时就把权限考虑进去。比如用户说“把这个工单转给张三”Agent 规划出的动作是“转派工单”这时候就应该先校验当前用户有没有转派权限张三是不是合法接收人两个都过了才生成执行计划。这样做的好处是如果权限不够Agent 可以直接告诉用户“你没有转派权限需要找主管”而不是执行到一半失败留下一个半完成的状态。半完成状态在业务系统里是最难清理的能避免就避免。3.3 敏感操作的二次确认与审计留痕有些操作即使权限够也不能让 Agent 自动执行比如删除数据、批量修改、对外发送。这类操作我统一加一道二次确认Agent 把要执行的动作、影响范围列清楚让用户明确点确认才真正执行。同时所有 Agent 发起的动作都要留审计日志记录清楚谁发起的、什么时间、Agent 规划了什么、实际执行了什么、结果如何。这份日志在出问题时是救命稻草。我一般会把日志结构设计成下面这样{ trace_id: 唯一追踪ID, user_id: 发起用户, session_id: 会话ID, intent: 识别到的意图, planned_actions: [规划的动作列表], executed_actions: [实际执行的动作], permission_check: 权限校验结果, result: 执行结果, timestamp: 时间戳 }有了 trace_id一次会话里所有环节都能串起来排查问题效率翻倍。4. 动作执行让 Agent 干活但别让它闯祸4.1 工具调用的边界设计只暴露必要的接口Agent 能调哪些工具是安全的第一道闸门。我的原则是最小暴露只给它当前任务真正需要的接口而且每个接口都要做参数校验和范围限制。举个例子查询订单的接口不要给它一个“传任意 SQL”的能力而是封装成“按订单号查”“按时间范围查”“按客户查”几个明确的函数。每个函数内部再做参数合法性检查比如时间范围不能超过 90 天单次返回不能超过 100 条。这样即使模型被诱导也闯不出大祸。工具描述也要写清楚边界。我见过工具描述写得太模糊模型以为能查全量数据结果传了个空参数把整张表拉出来了。工具描述里一定要写明必填参数、可选参数、返回上限、适用场景。4.2 幂等与回滚动作执行的安全网真实业务里动作执行失败是常态网络抖动、下游超时、并发冲突都会导致失败。如果 Agent 重试时不做幂等就可能重复下单、重复发消息。所以每个写操作接口都要支持幂等键Agent 每次执行带一个唯一键下游系统根据这个键去重。回滚更复杂一些。对于多步操作我一般用补偿事务的思路每一步都记录正向操作和对应的补偿操作如果中途失败就按逆序执行补偿。比如“创建工单”失败了就补偿“删除工单”“扣减库存”失败了就补偿“回补库存”。这套机制要在 Agent 框架层面统一实现不能指望每个工具自己处理。4.3 失败重试与人工兜底的分界线不是所有失败都值得重试。我的经验是分三类处理瞬时故障网络超时、限流自动重试 2 到 3 次指数退避。业务规则拒绝权限不足、状态不允许不重试直接反馈用户。未知异常重试一次还失败就转人工。转人工这个兜底特别重要。Agent 再聪明也有搞不定的时候这时候要能平滑地把上下文交接给人工坐席而不是让用户重新描述一遍。我一般会把当前会话的摘要、已执行的动作、失败原因打包成一个工单人工接手时一目了然。5. 上线之后观测、评估与持续迭代5.1 别只看“回答对不对”要看“动作准不准”评估 Agent 的指标很多人只看回答质量。但接进业务流程后更关键的是动作准确率它规划的动作对不对、参数填得对不对、执行成功率多少。我一般会盯这几个指标指标含义健康值参考意图识别准确率理解用户想干什么95% 以上槽位填充完整率关键参数是否齐全90% 以上动作规划准确率规划的动作是否合理90% 以上动作执行成功率实际执行是否成功98% 以上人工转接率需要人工兜底的比例10% 以下这些指标要按天看趋势突然掉下来往往意味着上游数据或接口变了。5.2 用真实会话做回归测试每次改提示词、换模型、加工具都要跑一遍回归测试。测试集从哪来就从真实会话里采样。我一般会攒一个 200 到 500 条的测试集覆盖高频场景和已知的坑每次改动都跑一遍看指标有没有退化。这比拍脑袋上线靠谱得多。测试集要定期更新把新出现的失败案例加进去。我习惯每周花半小时过一遍本周的失败会话挑典型的补充进测试集。这个习惯坚持下来Agent 的稳定性会肉眼可见地提升。5.3 迭代节奏小步快跑但要有回滚能力Agent 的迭代不能像传统软件那样攒个大版本再发。我的做法是灰度加开关新版本先放 5% 流量观察指标没问题再逐步放量。同时每个能力都要有开关出问题能一键关掉降级到人工或旧逻辑。这套机制听起来麻烦但真出事的时候能救命。我经历过一次模型供应商那边接口抖动导致动作执行大面积失败幸好有开关五分钟内切回旧逻辑业务没受大影响。从那以后我对“可回滚”这件事的重视程度提到了最高。6. 几个我踩过的坑和对应的解法6.1 上下文里的“脏数据”比没有数据更可怕有一次 Agent 回答客户问题时引用了错误的订单金额排查半天发现是上游数据同步延迟上下文里拿到的是旧值。模型本身没错错在数据源。后来我加了一道数据新鲜度校验关键字段带时间戳超过阈值就标记为“可能过期”让 Agent 在回答时主动说明或者干脆重新拉取。6.2 权限校验别信模型自己判断早期我试过在提示词里写“请只查询当前用户有权限的数据”指望模型自觉。结果模型该查还是查。权限这种事必须靠代码卡不能靠提示词。提示词是建议代码才是约束。6.3 工具描述写不好模型就会乱调工具描述是模型理解工具的唯一途径。我踩过的坑是描述里没写清楚参数格式模型传了个自然语言字符串进去接口直接报错。后来我把每个工具的描述都按“功能、参数、返回、示例”四段式写模型调用准确率明显提升。这个投入非常值。6.4 别让 Agent 一次做太多事一个 Agent 如果既能查数据、又能改数据、还能发通知出问题的面就太大了。我的做法是按职责拆分查询类 Agent、操作类 Agent、通知类 Agent 分开各自权限和工具集独立。这样即使某个 Agent 出问题影响范围也可控。7. 写在最后的一点个人体会把 Agent 接进真实业务流程技术难度其实不在模型而在工程。上下文怎么给、权限怎么卡、动作怎么安全执行、上线后怎么观测这四件事做扎实了Agent 才真正从“玩具”变成“工具”。我自己的经验是前期在权限和审计上多花的时间后期都会以“少出事故”的形式还回来。如果你现在正卡在某个环节我的建议是先别急着优化模型效果回头看看上下文和权限这两块是不是有漏洞。很多时候Agent 表现不好不是它笨是我们没把该给的信息给对没把该卡的边界卡住。把这两件事理顺你会发现它的表现比想象中好得多。