1. 从“会聊天”到“能干活”企业 AI 的评判标准正在被重写过去两年企业里搞 AI 落地的人都有一个共同的尴尬演示的时候惊艳全场真到了业务流里能用的场景少得可怜。你问它一个问题它能给你一段漂亮的回答你让它把这件事从头到尾办完它就开始打太极。问题出在哪出在“回答”和“交付”之间隔着一条巨大的鸿沟。这条鸿沟里有什么有权限、有系统边界、有流程状态、有异常处理、有责任归属。一个能回答问题的模型本质上是一个信息转换器而一个能交付结果的系统本质上是一个任务执行体。这两者的架构逻辑、评估标准、风险模型完全不同。当行业头部玩家开始把 AI 从“对话助手”往“工作代理”方向推的时候真正被推到台前的不是模型能力又涨了多少分而是企业到底有没有准备好让 AI 去“动手”。我所在的团队在过去一年里前后参与了三个不同规模的企业 AI 集成项目从客服工单自动分类到供应链异常处理再到内部审批流的智能路由。踩过的坑、交过的学费让我对“工作代理”这四个字有了非常具体的理解。这篇文章不聊虚的就围绕一个核心问题展开当 AI 从回答变成交付企业需要跨过哪几道坎每一道坎背后的技术选型和实操细节是什么。适合谁来读如果你是企业里的技术负责人、产品经理或者正在负责 AI 落地的一线工程师这篇文章里的很多细节你大概率用得上。如果你只是对 AI 应用感兴趣也可以把它当作一份“企业级 AI 落地避坑指南”来看。2. 工作代理到底改变了什么三个维度的本质差异2.1 从信息输出到状态变更任务闭环的硬门槛一个对话式 AI 和一个工作代理最直观的区别在于前者输出的是文本后者输出的是状态变更。什么叫状态变更就是数据库里某条记录的状态从“待处理”变成了“已处理”就是某个工单被分配到了正确的处理人就是某笔异常交易被标记并触发了后续流程。这个区别听起来简单但实现起来完全是两码事。对话式 AI 的评估标准是“回答得对不对、好不好”工作代理的评估标准是“事情办没办成、办得对不对”。前者可以容忍一定程度的模糊和不确定性后者几乎不能容忍。你让一个代理去处理退款它不能给你一段“关于退款流程的分析”它必须真的把钱退回去并且确保金额、账户、时间戳全部正确。我在一个内部审批流的项目里就遇到过这个问题。最初我们用的是纯对话方案让模型判断一个申请该走哪个审批节点。模型判断得很准准确率能到 92% 左右。但问题是判断完之后呢它只是把结果输出到聊天窗口里还需要人工复制粘贴到审批系统里。这个“最后一公里”没打通整个方案的效率提升几乎为零。后来我们把它改造成代理模式让模型直接调用审批系统的 API判断完直接写入路由结果整个流程才算真正闭环。注意从对话到代理最大的认知转变是——你不再是在评估一个“回答质量”而是在评估一个“任务成功率”。这两个指标的优化方向完全不同。2.2 权限与边界代理能碰什么、不能碰什么工作代理一旦有了“动手”的能力权限管理就变成了第一优先级。对话式 AI 可以随便聊聊错了大不了道个歉工作代理如果权限没管好它可能删库、可能发错邮件、可能把不该审批的单子批了。我们在做供应链异常处理代理的时候设计了一套三层权限模型。第一层是“只读层”代理可以查询库存、物流、订单状态但不能做任何修改。第二层是“建议层”代理可以生成处理建议但需要人工确认后才能执行。第三层是“执行层”代理可以直接执行某些低风险操作比如重新分配库存、触发补货提醒。这套模型的关键在于每一层对应的操作范围必须白名单化。你不能告诉代理“你可以修改订单”你得告诉它“你可以修改订单的预计送达时间字段但仅限状态为‘运输中’的订单且修改幅度不能超过 48 小时”。这种颗粒度的权限控制是工作代理能否在企业里安全运行的基础。2.3 评估体系的重构从准确率到任务完成率对话式 AI 的评估相对成熟无非是准确率、召回率、BLEU 分数那一套。工作代理的评估要复杂得多。我们内部总结了一套“任务完成率”的评估框架包含四个核心指标指标名称定义目标值示例任务完成率代理独立完成的任务数 / 总任务数 85%一次通过率无需人工干预即完成的任务数 / 总任务数 70%平均完成时间从任务发起到状态变更的平均耗时 30 秒异常恢复率遇到异常后能自行恢复的任务数 / 异常任务总数 60%这四个指标里最容易被忽视的是“异常恢复率”。很多团队在 demo 阶段只测正常流程一上生产就发现各种边界情况。代理遇到一个没见过的错误码直接卡死然后整个流程就堵在那里。我们在实际项目里花了将近三分之一的时间在异常处理上包括重试策略、降级方案、人工兜底通道。3. 企业落地工作代理的四个核心技术模块3.1 任务规划与拆解把“一句话需求”变成“可执行步骤”工作代理接收到的输入往往是一句模糊的自然语言指令比如“帮我处理一下这批异常订单”。这句话里没有说清楚哪些订单算异常处理是指什么操作优先级怎么排代理需要把这些模糊信息转化成一系列可执行的步骤。我们采用的方案是“规划器 执行器”的双层架构。规划器负责把自然语言指令拆解成任务图执行器负责按图索骥地调用工具。规划器的输出不是一段文本而是一个结构化的任务列表每个任务包含操作类型、目标对象、参数、依赖关系、超时时间。举个例子“处理异常订单”经过规划器拆解后可能变成这样一个任务图查询状态为“异常”的订单列表依赖无对每个订单查询其异常原因依赖步骤 1根据异常原因分类地址错误、库存不足、支付失败依赖步骤 2对地址错误的订单调用地址修正服务依赖步骤 3对库存不足的订单触发补货或取消通知依赖步骤 3对支付失败的订单重新发起扣款或通知用户依赖步骤 3汇总处理结果并生成报告依赖步骤 4、5、6这个任务图的关键在于每一步都有明确的输入输出定义每一步都可以独立重试每一步都有超时和异常处理。规划器的质量直接决定了代理能不能处理复杂场景。我们在实际测试中发现规划器最容易犯的错误是“步骤遗漏”和“依赖关系错误”。前者导致任务做了一半就停了后者导致步骤执行顺序错乱。实操心得规划器的 prompt 里一定要加入“完整性检查”环节让模型在输出任务图后自己再检查一遍是否有遗漏的步骤、是否有循环依赖、是否有不可达的节点。这个自检环节能把规划错误率降低 40% 左右。3.2 工具调用与 API 集成代理的“手脚”怎么长出来工作代理要干活必须能调用外部工具。这些工具可能是内部的 REST API、数据库查询、消息队列也可能是第三方的 SaaS 服务。工具调用的核心挑战不在于“能不能调”而在于“调得对不对、稳不稳、快不快”。我们内部有一套工具注册规范每个工具必须提供以下元信息工具名称和描述给规划器看的描述要精确到参数级别输入参数 schema类型、必填/选填、取值范围、默认值输出结果 schema成功和失败两种情况的返回结构错误码列表每个错误码的含义和建议的处理方式超时时间和重试策略权限要求调用该工具需要什么级别的权限这套规范看起来繁琐但它是代理稳定运行的基础。我见过太多团队工具描述写得模棱两可规划器根本不知道什么时候该调、怎么调结果就是代理要么不调工具要么乱调工具。工具调用的另一个坑是“幂等性”。代理可能会因为超时重试而重复调用同一个工具。如果这个工具不是幂等的就会出问题。比如“创建订单”这个操作重复调用就会创建多个订单。我们的做法是所有写操作必须支持幂等键代理在调用时带上一个唯一标识服务端根据这个标识去重。# 工具调用的幂等性封装示例 def call_tool_with_idempotency(tool_name, params, idempotency_key): # 先检查该 key 是否已经执行过 if cache.exists(idempotency_key): return cache.get(idempotency_key) # 执行工具调用 result execute_tool(tool_name, params) # 缓存结果设置合理的过期时间 cache.set(idempotency_key, result, ttl3600) return result3.3 记忆与上下文管理代理怎么记住“刚才发生了什么”对话式 AI 的上下文管理相对简单就是把历史消息拼在一起。工作代理的上下文管理要复杂得多因为它需要记住的不只是“说了什么”还有“做了什么”、“做到哪一步了”、“遇到了什么问题”。我们把代理的记忆分为三层短期记忆当前任务的执行状态包括已完成步骤、当前步骤、待执行步骤、中间结果。这层记忆存在内存里任务结束后释放。中期记忆最近 N 个任务的执行摘要用于跨任务的经验复用。比如代理发现某个 API 经常超时下次调用时就会自动延长超时时间。长期记忆领域知识和业务规则以向量数据库的形式存储代理在规划任务时会检索相关规则。这三层记忆的管理策略完全不同。短期记忆要求强一致性不能丢中期记忆可以容忍一定的丢失但要求快速读写长期记忆要求高召回率对延迟不敏感。我们在实际项目里踩过一个坑最初把三层记忆混在一起存结果短期记忆的频繁读写把长期记忆的检索性能拖垮了。后来拆成三个独立的存储层各自用最适合的技术方案问题才解决。3.4 异常处理与人工兜底代理“卡住了”怎么办工作代理最怕的不是做错而是卡住。做错了可以回滚卡住了整个流程就堵死了。异常处理机制的设计直接决定了代理能不能在生产环境里跑得稳。我们的异常处理策略分四级自动重试对于网络超时、临时限流这类瞬时错误自动重试 2-3 次每次间隔指数退避。降级执行对于某个工具不可用的情况尝试用备用工具或简化流程完成核心目标。任务挂起对于需要人工决策的异常把任务挂起并通知相关人员保留完整的执行上下文。安全回滚对于已经产生副作用的操作如果后续步骤失败执行补偿操作回滚已做的变更。这四级策略的触发条件需要精确配置。触发条件太宽松代理会频繁重试导致雪崩触发条件太严格代理会过早放弃本可以自动恢复的任务。注意人工兜底通道不是“失败后的无奈之举”而是整个代理系统设计的一部分。我们在设计之初就会明确哪些任务必须有人工确认环节哪些异常必须通知人工人工介入后代理如何恢复执行。这些流程要在上线前全部跑通。4. 一个完整的工作代理落地实录从需求到上线4.1 场景选择与可行性评估我们选的场景是“客服工单智能路由与初步处理”。这个场景的特点是任务边界清晰、有明确的状态流转、异常情况可控、人工兜底容易实现。选场景的时候我建议优先考虑这三个条件流程标准化程度高、错误代价可控、有现成的人工流程可以对照。可行性评估我们用了五个维度打分维度评估问题本项目得分1-5流程清晰度任务步骤是否明确可枚举4系统集成度所需 API 是否齐全稳定4异常可控性出错后是否容易回滚5数据可得性是否有足够的历史数据训练/评估3人工兜底成本人工介入是否方便5总分 21 分超过 18 分才建议启动。这个评分表帮我们排除了好几个看起来很美但实际很难落地的场景。4.2 代理架构设计与技术选型我们的代理架构分为四层接入层接收工单系统的 webhook做初步的格式校验和去重。规划层调用大模型进行任务规划输出结构化的任务图。执行层按照任务图逐步调用工具管理执行状态和异常。监控层记录每一步的执行日志计算任务完成率等指标触发告警。技术选型上规划层我们用了两个模型做交叉验证一个负责生成任务图另一个负责审核任务图的合理性。两个模型都通过才进入执行层否则打回重新规划。这个双模型机制把规划错误率从 15% 降到了 6% 左右。执行层的工具调用我们封装了一个统一的 ToolExecutor所有工具调用都走这个入口方便做权限校验、限流、重试、日志记录。这个封装看起来多了一层但后期排查问题的时候非常省事。4.3 关键参数配置与调优过程代理系统里有一堆参数需要调我挑几个最关键的说说规划超时时间最初设了 30 秒结果发现复杂工单的规划经常超时。后来改成动态超时简单工单 15 秒复杂工单 60 秒。判断标准是工单描述的字数和历史相似工单的平均规划耗时。工具调用重试次数默认 3 次但对于写操作只重试 1 次。因为写操作重试的风险更高宁可失败后走人工兜底也不要重复执行。任务挂起阈值当一个任务连续失败 3 次或者挂起时间超过 2 小时自动升级为高优先级告警通知人工介入。上下文窗口大小短期记忆保留最近 20 个步骤的完整信息中期记忆保留最近 100 个任务的摘要。这个数值是根据实际 token 消耗和检索延迟调出来的太小会导致代理“失忆”太大会拖慢规划速度。调参的过程就是不断在“代理自主性”和“人工干预频率”之间找平衡。自主性太高错误率上升自主性太低人工成本降不下来。我们最终把一次通过率稳定在 72% 左右人工干预率控制在 28%这个比例在业务方看来是可以接受的。4.4 上线后的监控指标与迭代节奏上线不是终点而是起点。我们设了三个核心监控看板实时看板当前正在执行的任务数、平均执行时长、异常任务数。日报看板任务完成率、一次通过率、异常分类分布、人工干预原因分布。周报看板趋势变化、新增异常类型、工具调用成功率排名。迭代节奏上前两周每天复盘一次异常案例把高频异常逐个解决。两周后改成每周复盘一次重点看趋势和长尾问题。上线第一个月任务完成率从 68% 提升到了 85%主要靠的就是异常处理的持续优化。5. 常见问题与排查技巧实录5.1 代理“不听话”规划器输出格式错误的排查这是最常见的问题。规划器输出的任务图格式不对执行层解析不了整个任务就卡住了。排查思路分三步第一步检查 prompt 里的格式约束是否足够明确。我们最初只说了“输出 JSON 格式”结果模型经常输出带 markdown 代码块的 JSON或者字段名大小写不一致。后来改成“输出纯 JSON不要用代码块包裹字段名严格遵循以下 schema”格式错误率大幅下降。第二步加一层格式校验和自动修复。对于常见的格式问题比如多余的逗号、缺失的引号写一个修复函数自动处理。修复不了的再打回重新规划。第三步如果格式错误率仍然很高考虑换模型或者加 few-shot 示例。我们在 prompt 里放了 3 个正确输出的示例格式错误率从 12% 降到了 3% 以下。5.2 工具调用超时是网络问题还是参数问题工具调用超时的原因很多排查的时候要按顺序排除排查步骤检查内容常见问题1网络连通性DNS 解析失败、防火墙拦截2工具服务状态服务是否在运行、是否过载3请求参数参数是否合法、是否缺少必填项4超时设置超时时间是否太短、是否没有设置5幂等性是否因为重试导致重复调用我们遇到最多的是第 3 步参数问题。规划器生成的参数有时候不符合工具的要求比如日期格式不对、枚举值拼写错误。后来我们在工具注册信息里加了参数校验规则执行层在调用前先做一轮本地校验把明显不合法的参数拦截下来超时率降低了 30%。5.3 任务卡死如何快速定位阻塞点任务卡死是最让人头疼的问题因为代理不报错就是不动了。我们的排查方法是在每个步骤执行前后都打日志日志里包含任务 ID、步骤序号、步骤名称、开始时间、结束时间、状态。任务卡死的时候看日志就能知道卡在哪一步。如果日志显示某一步开始了但没有结束那就是这一步阻塞了。常见原因有工具调用没有设置超时、工具返回了预期之外的结果导致解析死循环、依赖的上一步结果为空导致当前步骤无法执行。实操心得给每个步骤设置一个“最大执行时间”超过这个时间强制标记为超时并进入异常处理流程。这个机制能防止单个步骤卡死拖垮整个任务。5.4 人工兜底通道的响应延迟优化人工兜底通道的响应速度直接影响整体效率。我们最初用邮件通知平均响应时间超过 2 小时。后来改成企业即时通讯工具的消息推送响应时间降到了 15 分钟以内。再后来加了移动端推送响应时间进一步降到 5 分钟左右。除了通知渠道通知内容的格式也很重要。最初我们只发一句“有任务需要人工处理”人工介入后还要自己去翻上下文。后来改成推送完整的任务上下文任务 ID、当前步骤、已完成步骤、异常信息、建议的处理方式。人工介入的效率提升了一倍多。6. 工作代理落地的经验与边界思考6.1 哪些场景适合优先上代理根据我们的实践经验以下特征的场景适合优先考虑工作代理流程步骤明确可以枚举出所有可能的操作每个步骤的输入输出都有清晰的 schema异常情况有成熟的分类和处理方案人工兜底的成本可控不会因为代理出错导致严重后果有足够的历史数据用于评估代理的表现反过来以下场景建议先缓一缓流程涉及大量主观判断、步骤之间的依赖关系复杂且动态变化、错误代价极高且难以回滚、缺乏历史数据无法评估效果。6.2 代理与人工的协作边界怎么划代理和人工的协作边界不是一成不变的而是随着代理能力的提升动态调整的。我们的做法是初期把边界划得保守一些代理只做最确定的部分大部分环节都有人工确认。随着代理在某个环节的准确率稳定在 95% 以上逐步放开这个环节的自动执行权限。这个“逐步放开”的过程需要数据支撑。我们每周会统计每个环节的代理准确率和人工干预率准确率高且干预率低的环节就是可以放开的候选。放开之后继续监控如果准确率下降随时可以收回权限。6.3 从“能用”到“好用”还差什么从 demo 到能用差的是工程化从能用到好用差的是体验优化。我们上线后收到的反馈里最多的不是“代理做错了”而是“我不知道代理在做什么”。代理执行过程中缺乏透明度人工不知道它做到哪了、遇到了什么问题、为什么做了这个决策。后来我们加了一个“执行轨迹”页面把代理的每一步决策都展示出来调用了什么工具、传了什么参数、返回了什么结果、为什么选择这个工具而不是另一个。这个页面上线后人工干预的效率明显提升因为介入的人能快速理解代理的“思路”知道该从哪里接手。6.4 后续可以扩展的方向工作代理的架构搭好之后可以扩展的方向很多。我们目前在探索的有两个一是多代理协作让不同专长的代理互相配合完成复杂任务二是代理的自我优化让代理根据历史执行数据自动调整规划策略和工具调用参数。多代理协作的挑战在于代理之间的通信和协调。我们初步的方案是定义一个标准的消息协议代理之间通过消息队列通信每个代理只关心自己负责的子任务。这个方案还在实验阶段效果好的话后续再单独写一篇分享。代理的自我优化相对容易落地一些。我们已经在做的记录每次工具调用的实际耗时动态调整超时时间记录每次规划的实际执行结果把成功的规划模式作为 few-shot 示例加入 prompt。这两个优化都不需要改架构但效果立竿见影。我个人在实际操作中的体会是工作代理的落地难点从来不在模型能力上而在工程细节上。权限怎么管、异常怎么处理、状态怎么同步、人工怎么介入这些看起来不性感的问题才是决定代理能不能真正跑起来的关键。把这些问题一个一个啃下来代理的价值自然就体现出来了。