这两年跟很多做企业数字化的人聊大家有个共同的感受AI 试得很热闹用得很少。让模型写文案、写代码、翻译文档个个都是一把好手但真到了“把一摊子事办完”的环节模型就停住了。什么叫“办完一摊子事”比如拿到一张销售数据表自动清洗、汇总、做图最后把报告发进工作群——这才叫交付。绝大多数 AI 产品到今天为止只能给你一段文字叫做“建议”不叫“方案”。谷歌最近把 Gemini 往“工作代理”方向推就是冲着这个缺口去的让 AI 从“提供回答”升级成“交付结果”。对企业来说考题跟着变了——过去问 AI 答得好不好现在问 AI 能不能把活干完。这篇文章我打算把三件事说透这个转变到底是什么企业要怎么接住以及我自己把一个代理型 AI 落地时踩过的那些坑。1. 说说“工作代理”它到底改变了什么1.1 回答型 AI 和代理型 AI差在哪里先说一个不那么精确但特别直观的类比。回答型 AI 像是你请来的一个口才极好的顾问肚子里装满了知识你问什么它都能说上几个小时但它说完之后该你干活还是你干活。代理型 AI 则更像一个来了就上手的实习生你给它一个目标它会自己去查资料、整理表格、联系工具、把结果交给你。前者交付的是“话”后者交付的是“事”。这个差别的技术根源在于任务形态完全不同。传统的大语言模型输入的是一条问题输出的是一段文本整个过程是“一次推理、一次生成”。模型不会去检查这句话对不对不会为了完成一个目标主动去调用外部系统更不会在发现步骤出错之后自己回头改。代理型 AI 则建立在一个“循环执行”的架构上模型先规划接着行动观察结果再重新规划直到任务完成。这个循环的引入让模型从“单次对话”进入“持续工作状态”。我把两种形态做过一次对比特点非常清晰维度回答型 AI代理型 AI任务形态一问一答多步任务闭环输入目标一段问题一个明确要交付的结果输出产物文本、代码、知识处理后的数据、完成的动作、生成的文件过程控制无生成即结束有状态可追踪可中断失败处理依赖用户重问自主重试、改路径或请求人工评判标准说法对不对、通不通任务是否完成、交付质量这个表格基本上就是企业选型时会关心的全部维度变化。需要补充的是代理型 AI 并不是一个全新的模型架构而是在已有大模型能力之上增加了三层能力第一是工具调用模型可以主动调用数据库、接口、办公软件第二是任务规划模型会把大目标拆成小步骤并排序第三是反思机制执行完一步后评估结果决定继续还是换个方案。Gemini 这次被推向“工作代理”本质就是把这三层能力产品化放到企业可用的工程框架里。1.2 Gemini 的这步棋换了个“考核维度”如果只看模型参数Gemini 的进化可能只是“更聪明了”。但从企业使用者的角度看真正的变化不是模型聪明而是评价标准变了。过去我们评价一个模型默认的指标是“答得准不准”。尤其在知识问答、内容生成这类任务里模型的答案是不是有依据、逻辑顺不顺基本决定了它的价值。但企业干活不是这么回事。企业里的任务比如“把上个月的订单数据整理成一张可以发给财务的对账表”它的成败边界非常清楚表有没有生成数字对不对格式能不能被财务系统读进去这一切都和执行过程有关和模型写了多少优美的解说词无关。Gemini 被改造成工作代理相当于把一个“答题型选手”送进了“工程型赛场”。它需要理解目标、拆分步骤、调用工具、验证结果。这背后其实是一套工程系统的变化包括任务运行时、工具接口协议、状态存储、权限管理、人工介入机制。这些组件共同决定了 AI 能不能在企业里真正交付。所以别只盯着“Gemini 好像变强了”这个表象。更值得关注的是AI 产品开始以“是否把活交付出来”作为核心考核指标。这会倒逼整个企业 AI 的玩法改变——技术上要从调参转向搭系统管理上要从追热点转向定流程采购上要从比参数转向比交付率。2. 企业 AI 的真正考题从答得对到交得出2.1 三个常见场景看看“回答”为什么不够场景一数据处理。某电商团队的运营同事每天要做一件很繁琐的事从后台导出前一天的订单明细用表格软件打开删掉异常订单按品类汇总再生成一张趋势图最后贴进工作群。如果让回答型 AI 来做它顶多告诉你“按这个步骤操作”然后继续等你手动完成。而代理型 AI 的逻辑是直接把这些步骤拆成工具调用读取导出文件、清洗数据、生成聚合表、渲染图表、调用接口发到群。前者是“教你干活”后者是“替你干活”。场景二客户服务。最常见的客服场景是“查订单、退换货、催进度”。这些操作都要访问订单系统、库存系统、通知服务。传统 AI 客服把问题回答得再溜不连接后台系统就只是摆设。代理型 AI 的交付则是一个完成的动作比如订单状态已经更新、退换货流程已经发起、通知已经推送。场景三行政协同。安排一场跨部门会议需要查参与者的空闲时间、预订会议室、发出邀请、收集确认。回答型 AI 只能把流程说一遍代理型 AI 直接帮你把会议建好、通知发完然后把结果回执放在你面前。三个例子的共同点企业的真实需求从来不是“获得一段解释”而是“完成一个动作、得到一个结果”。回答只是一层外壳交付才是核心。2.2 “交付”二字意味着什么“交付”听起来是个很普通的中文词但放在 AI 语境下它意味着三个非常重要的变化。第一任务有闭环了。一个问题抛给代理型 AI它会一直执行到目标达成或者明确告诉你它卡在哪里。不再像传统对话那样回答完就撒手不管。第二质量可验收了。交付结果是文件、动作、数据状态能不能验收、符不符合预期都是确定性的。企业可以给 AI 设 KPI可以统计一次任务的成功率可以评测它和人力的时间对比。这在过去没法量化。第三过程可审计了。代理执行过程中的每一次工具调用、每一步决策、每一条错误日志都可以被记录。一旦出了问题管理者能回溯到底发生了什么。对金融、医疗、法务等强监管行业来说这是能落地的前提。从回答到交付表面上是产品功能的变化本质上是一套考核体系的迁移。一个只会讲道理的员工企业不一定愿意付高薪一个能把事做完的员工才有资格谈价值。AI 也是一样。3. 把一个最简 Agent 跑起来可复现的实操3.1 选场景的原则如果你也想像我一样亲手体验一次代理型 AI别上来就挑战复杂流程。选错场景大概率会劝退。我建议按这四个标准选第一个实验场景开始和结束状态都非常明确比如“读取某个目录下的所有 CSV合并后输出一张总表”。涉及的工具不超过两个且都是稳定接口降低排障成本。执行失败后影响很小比如本地文件处理而不是直接发真实邮件给客户。高频重复能明显感觉到人工做很费时间AI 做有意义的场景。按这个标准我最推荐从“批量文件整理 邮件通知”或者“数据库查询 报告生成”入手。这类任务覆盖了工具调用、数据格式化、结果反馈三个核心环节又不会一上来就碰到权限和安全的大坑。3.2 核心循环代码骨架代理型 AI 的工程实现有很多框架但内核都是同一个循环决定下一步做什么执行看结果决定再下一步。我用一段接近工程实现的 Python 把核心逻辑写出来结构比框架更重要# agent_loop_demo.py # 最简“工作代理”循环骨架用于理解执行原理 class MinimalAgent: def __init__(self, model, tools, max_steps6): self.model model # 大模型接口用于规划和决策 self.tools tools # 可调用的工具字典如 {query_db: func, send_mail: func} self.max_steps max_steps def run(self, goal: str): context [] # 保存历史执行记录 for step in range(self.max_steps): # 1. 决策模型根据目标、历史、可用工具决定下一步动作 action self.model.decide( goalgoal, historycontext, toolslist(self.tools.keys()) ) # 2. 执行调工具还是产出最终结果 if action[type] call_tool: result self.tools[action[name]](**action[args]) context.append({step: step, action: action, result: result}) # 3. 校验结果是否说明任务已完成 if self.model.check_done(goal, context): return self.model.final_answer(goal, context) elif action[type] answer: return action[content] else: raise ValueError(f未知动作类型: {action[type]}) # 超过最大步数主动停止并交给人工 return {status: needs_human, reason: step_limit}这段代码我把决策、执行、检查三个动作放进了同一个循环就是为了体现工作代理的核心逻辑模型不是一次性输出答案而是在一个可控的循环里反复决策。真实的生产系统会比这复杂得多会引入状态持久化、权限校验、并发控制、审计日志但骨架一定是这样。试跑一个具体任务比如“查询昨天订单量并汇总成 JSON 发给指定邮箱”流程可以写成这样第一步模型把“查询昨天订单量”映射到 query_order_count 工具第二步执行工具拿到数字第三步模型判断目标还差“汇总成 JSON”于是再次调用 format_to_json 工具第四步检查到所有子目标都完成了再调用 send_email最后返回成功状态。这就是一个完整的最小交付循环。3.3 四个必须调好的参数实操中我发现参数配置对 Agent 稳定性的影响甚至大于模型选择。这里列四个最重要的参数作用我的建议值max_steps限制循环步数防止任务跑飞6-10 步复杂任务最好用多段运行时tool_timeout单次工具调用的超时上限5-15 秒按接口 P95 耗时给temperature控制决策随机性规划阶段 0-0.2生成内容阶段可调到 0.7retry_policy工具失败后的重试策略指数退避最多 2 次超限转人工max_steps 是最容易被忽略的。理论上一个 Agent 可以无限执行下去但真实世界里模型偶尔会陷入“重复调用同一个工具却观察不到有效进展”的循环里。没有步数上限成本会滚雪球。我给本地实验设的默认值是 6生产环境建议拆成多段任务每段单独设上限。temperature 在规划阶段要特别低。Agent 的决策环节容不得“灵感”同样的输入如果能稳定得到同样的动作序列后续排障才可能。我一般把规划推理的温度调到 0 附近让模型尽量走确定性路径只有最后生成报告文案这类创造性输出时才把温度调高。3.4 提示词的“任务契约”写法用代理型 AI提示词不再是“问一句答一句”的对话而是一份任务契约。我总结了一个好用的模板你是【角色】负责完成以下任务。 任务目标【一句话讲清楚要交付的结果】 完成标准【列出可以客观验收的条件例如文件生成、数据无误、通知已发】 可用工具【一一列出不在此列表中的操作一律禁止】 禁止行为【例如删除数据、调用未知接口、直接回复用户而不执行】 边界条件【哪些情况必须停下来询问人工例如金额超过阈值、目标不明确、工具连续失败】这份契约的价值在于给模型划清楚了“可以做什么、不可以做什么、做到什么程度算完”。大量 Agent 失控问题的根源往往不是模型不够聪明而是任务边界不清楚。我遇到过模型自作主张把“汇总上周数据”执行成“删除三个月前旧数据”的情况就是因为提示词里没有明确禁止写操作。4. 从 Demo 到生产企业落地避坑指南4.1 权限与数据安全代理型 AI 最危险的特性是“会动手”。对话型 AI 无论怎么胡说它不碰任何系统代理型 AI 一上线就有了操作数据库、发邮件、改文件的真实能力。权限设计必须从第一天就当第一优先级的问题处理。我的建议是分三层控制第一层工具接口本身的权限做到最细AI 用的服务账号只拥有完成任务所需的最小权限第二层凡是涉及删除、修改、对外发送的操作默认加一道人工审批第三层所有执行动作留完整审计日志包括入参、出参、调用者、时间戳。宁可多一步人工确认也不要让 AI 直接在核心系统里裸奔。4.2 工具的幂等性幂等性这个词听起来拗口但它是 Agent 落到生产环境的生死线。简单说同一个操作执行一次和执行十次最终结果必须一致。为什么重要因为 Agent 天然会重试。工具超时了它要重试模型判断状态异常了它可能再调一次。如果这个操作是“发送邮件”“扣减库存”“创建订单”不具备幂等性的接口会被重复执行出大事故。解决方案是给每个请求加 request_id服务端做去重或者在工具接口里实现状态检查比如“查找未完成订单”后再决定是否创建新订单。这是个非常工程化的细节但踩过坑的人都知道它比调模型参数重要得多。4.3 人工审核节点全自动的 Agent 听起来很爽但企业落地第一步别追求全自动。我见过不少团队上线 Agent 后的第一个事故就是模型自作主张执行了一个“看似合理但违背业务规则”的操作。保险的做法是设置人工确认点任务启动前让 Agent 先输出它的执行计划给人看一眼第二个确认点放在高风险动作之前任务结束之后保留可回滚的撤销机制。运营一段时间后根据历史成功率逐步打掉多余的人工节点。这个渐进式放权既保住了效率也保住了安全。4.4 成本与延迟管理Agent 的本质是“用多次模型调用换一个结果”。一次简单任务可能产生 3-8 次大模型调用复杂任务可能是几十次。成本不是按任务算的是按步数算的。要控制成本第一步是节流参数也就是前面说的 max_steps 和重试上限第二步是分级模型策略规划用大模型工具参数提取用中等模型最终文案可以用快速模型第三步是缓存对于重复性极高的任务把已经跑通过的计划模板缓存下来下次直接从固定的工作流执行不再让模型重新规划。延迟方面异步执行比同步等待友好得多给用户一个任务进度页比一直转圈等结果体验好很多。4.5 幻觉在任务链里会被放大对话型 AI 说错一句话用户笑一下就过了。代理型 AI 在任务链里的每一个幻觉都可能产生真实副作用。比如模型把“同步库存”幻觉成“清空库存备份表格”或者把参数填错后仍然自信地继续后续步骤。针对幻觉我的经验是加“结果校验器”。每执行完一步不只看模型的自我判断而是用规则去校验产出物数据表的关键字段是否为空、数量是否合得上、状态码是否正常。规则校验不到的环节保留抽样人工抽检。把“校验”当成 Agent 系统里的一个独立组件而不是模型的附属功能。5. 常见问题与排查速查表把实操中高频出现的问题整理成一张表方便排查现象可能原因排查方法Agent 反复执行同一个工具不停止缺结束条件上下文里结果未被正确记录检查提示词完成标准打印每步返回的完整上下文工具调用的参数明显错误模型对接口文档理解不足参数描述不清优化工具描述把每个参数的含义、格式、示例写清楚任务执行到一半直接“编结果”模型幻觉缺少产出校验增加规则校验器关键产出必须过校验成本飙升远超预算步数没设上限重试策略过激进检查 max_steps重试次数降到 2 次以内考虑缓存明明有权限工具却报鉴权失败工具内部源码传参错误密钥管理混乱查看工具本身异常日志确认调用链路身份字段透传模型把用户历史对话当成当前任务目标上下文没有分段把任务目标字段与历史记录彻底分开存储每次拼接时只取任务相关部分这张表我每一条都实际遇到过。最有共性的其实还是第一行Agent 跑飞。跑飞的原因里真不是模型笨而是任务边界和结束条件没写清楚。把提示词里“什么算完成”写实很多问题能少一大半。6. 聊聊实际体感与一些建议说点实际操作下来的真实感受。第一次把一个任务完整交给代理型 AI让它自己去查数、整理、发送最后回到我这里报告“已完成”的时候那种体验确实不一样。过去用 AI我是一个一个指令地下像开手动挡用工作代理我更像是一名主管只要说清楚目标和边界它会把过程拆好。这种角色的变化会让人重新理解“和人协作”是什么。但我也必须提醒一句工作代理目前的成熟度还远没有到“交给它就能撒手不管”的水平。我最近跑的一个场景是“定期整理运营周报”整体成功率大概在七八成剩下的失败源于工具偶发异常、数据格式变化、任务步骤本身表述歧义。这反而说明方向选对了因为有七八成的时间省下来了就是实实在在的效率。给准备尝试的朋友三个建议。第一从最小的、低风险的任务开始别一上来就做跨系统的复杂编排。第二把“人工可介入”设计成默认选项给 Agent 一个随时可以向人求助的通道。第三别把希望全部寄托在模型升级上把你自己的业务流程、接口规范、数据字典整理好这才是 Agent 能否落地的地基。最后说一句真实的判断企业 AI 从“回答”走向“交付”不是一个技术口号能概括的它会逼着每一家企业重新回答一个问题——你要的是会说道理的专家还是能交出结果的员工。对这个考题我的答案已经很明确了。