飞猪、货拉拉、江苏移动专家对谈：企业 Agent 的壁垒不在模型，在边界与业务知识

原创 QCon 2026-10-29 13:30 北京

企业 Agent 真正的壁垒，不在模型？

作者 | QCon 全球软件开发大会

策划 | Kimmy

编辑 | 宇琪

如果 Agent 只是回答一个问题，答错了，用户可能再问一次；但如果 Agent 开始下单、参与调度、修改生产系统、调用真实业务能力，那么一次错误可能带来的就不只是体验问题，而是实际业务风险。那么，企业 Agent 的边界，到底在哪？

近日，InfoQ《极客有约》X QCon 直播栏目特别邀请NoDesk AI CTO 王仿担任主持人，和飞猪算法专家吕德涛、货拉拉技术总监亓隆基、江苏移动 AI 方向 CTO 王上淇一起，在QCon全球软件开发大会 2026（上海站）即将召开之际，共同探讨企业级 Agent 的自主权与生产实践。

部分精彩观点如下：

业务场景更需要确定性和可靠性，这是模型天然不具备的，所以我们得有一个明确的边界，让模型的不确定性在确定的业务边界内进行。
关键环节还是用规则的方式做，只是描述和生成规则用 AI，成本、边界、准确性都解决了，可解释、可撤回、可控也更强。
涉及用户钱包权益的一定放在人这边；自由度高的，比如生成回复、澄清模糊意图、处理长尾表达，可以交给模型
企业 Agent 的壁垒，不是生成一份看起来不错的答案，而是企业自己的数据、工具、算法、业务规则、评测体系在真实世界里能不能成立

12 月 18–19 日，AICon 全球人工智能开发与应用大会将在北京举办。本届大会以探索 A 应用边界为主题，设置 13 大技术专题，覆盖大模型后训练、推理优化、Agent 工程、知识工程、智能体评测与安全、自进化系统、AI 软件交付、原生架构及组织变革等核心方向，汇聚一线技术专家，深入分享 AI 技术突破与企业规模化落地的真实实践。

以下内容基于直播速记整理，经 InfoQ 删减。

为什么现在要讨论 Agent 的边界？

王仿：为什么模型能力越来越强，我们反而越来越需要讨论 Agent 的边界？

吕德涛：模型越强，能处理更长程的任务、理解更复杂的需求、接触更多的业务状态。以前答错一个问题，用户还可能再问一次；但在真实业务里，推荐的价格或库存错了，会直接导致创单或支付失败，一旦进入交易链路就是严重的体验损失。而且模型很容易给出一个看起来很靠谱、其实是编造的答案，比如编一个很符合业务规则的酒店房型 ID，C 端用户完全感受不到。所以边界不是模型强弱的问题，而是它强了之后，怎么让明确的事情百分百保证正确。

亓隆基：这两年模型从只能回答问题到能调用工具，但原理上它还是基于 token 预测的概率模型，一定存在幻觉，是一种不确定的能力。进入真实业务，下单推荐、联系司机、撮合决策都是一笔真实的交易，犯错影响就大。业务场景更需要确定性和可靠性，这是模型天然不具备的，所以我们得有一个明确的边界，让模型的不确定性在确定的业务边界内进行。

王上淇：原来是对话框，答错用户再问一遍；现在是业务系统，出问题了谁都不能接受，比如移动内部 OA 办公批文推荐，批错领导后果就很严重，所以应用层面要通过 Harness 对 Agent 能力做校验。另一个是我做平台更有体会的：完全交给 Agent 去调大模型，对算力和 token 是浪费，网关也未必承载得住。原来防的是 DDOS，现在还要防 Agent 的无意攻击、无意消耗。算力 token 都要花钱，重试次数和边界机制没控制好，toC 产品会被这种 Agent 攻击，toB 产品会造成任务拥挤，我们生产就出现过某个智能体出问题、把整个生产带崩的情况。所以边界一头是能力，一头是系统稳定性。

王仿：我们有个客户是国内服饰领域一个 top 企业，内部 Agent 没做限制，直接去调内部数据库接口、并发也没限，把接口打崩了，影响线上半个多小时。所以从稳定性到业务逻辑，都要保证生产的确定性：服务得稳，业务规则在合规前提下执行，而不是跳出边界做事。

今天很多 Agent 已经能查信息、做分析、给建议，几位的实践却都在往更深处走，开始调用系统、改变状态、参与决策。Agent 从聊天助手到真正执行任务，跨过的是什么门槛？

吕德涛：跨过的不是会不会调用工具，而是能不能对最终结果负责。比如帮用户订上海迪士尼两大一小的门票：传统助手给个建议就好，到了业务系统里，要判断票种是不是成人票、两个大人一个小孩、人群范围对不对、有没有库存、组合出来的价格是不是最低，再进入订单流程，错一项都是回答得不好。我们会做几层约束：用模型做需求理解，票的组合、总价计算放到求解器里，保证结果可验证、可复算；酒店 ID、房型 ID 这类业务 ID 不会把原始值丢给模型，而是用短 ID 替换，展示时再回溯复原；涉及用户钱包的权益和支付，不直接开放给模型，要用户再确认。所以真正要跨的是校验、权限控制、可追溯的闭环。

亓隆基：我理解真正跨过去的，是原来很多必须由人做的事情，第一次可以由 AI 系统来完成。用户下单第一步是选车，我们有小车、大车，一个要运双开门冰箱的用户该选什么车？有了 Agent，我们把这些原本要用户自己具备的物流知识灌进去，让它帮用户理解意图、选车。这样业务系统就从单纯执行，变成了具备意图理解的能力。

王上淇：两个坎。第一是用户对 AI 的接受度不高。以前很多 AI 产品都是秒出的，而大模型要把文字转成向量、调接口、返回再渲染成 UI，流程完全不一样。我们给客户经理生成拜访方案，以前靠模板检索，现在让它先猜客户经理明天可能拜访哪家公司，提前结合内部资料和企查查把文档生成好，尽量命中请求，现场生成也能快很多。所以很大一部分工作是设计应用架构，该用 AI 时用 AI、不该用时少用，提前做缓存、预执行、预匹配。

第二是权限。企业内部能力原来都靠人操作，责任在人；toC 推荐对错用户还无所谓，企业内部批错单、批了不该批的，甚至没法追责。所以我们花很大精力做智能体权限管控，包括接口权限、MCP 能力权限，有权限的人才能用，责任就能落到人；遇到责任分摊和权限确认，就用 human in the loop 跟人确认，按公司规章设计 AI 交互。这有点像自动驾驶，L4 一直推不出来，L3 卡的不是技术，是职责和权限划分。

王仿：行业里不少 Agent 目前仍停留在演示或小范围试点阶段。toB 一个很重要的挑战是准确率，大家很少谈 Agent 准确率，默认模型聪明就不是问题，其实不是。比如进出口报关，前线业务同学拍的各种商品图片什么样的都有，先要解决感知问题，把不同模态的输入变成结构化文件，再审核、查询、交叉确认，生成报关和合同文件，以前全靠人做，一个报关要现场调研、四五十分钟以上。Agent 在这里最大的问题是准确率保证不了，不敢落地：手拍图片不同角度，解析商品编码、时间、日期戳很难保证；报关又很严肃，一个字段错整个申请就可能被驳回。

另一个影响准确的问题，是真要和业务专家面对面，把业务的目标、边界、拆解逻辑、背后依赖的规则都萃取成 Agent 能懂的语言，我们叫业务翻译。toB 和 toC 不一样，是人做了 80% 的活交给 Agent，而且一来一大批，十几个、几十个步骤走完还要稳定在 90% 或 95% 以上。除了权限，还有过程不能黑盒：人可以不看，但想看哪个环节，点进来就要把 Agent 的全过程，解析了哪些字段、为什么通过、为什么不通过、背后依赖什么逻辑，都提示出来。QClaw 刚出来时我以为企业端落地能进一大步，但并没有，因为它黑盒、保证不了准确，也解决不了权限。这在 toB 非常显著，也是 Agent 大规模落地的阻力。

吕德涛：我们有类似的场景，toB 客服的退款、退改规则，错一个就是一笔资损。

王仿：我见过一个做宠粮的企业做包材审核，包材审核出现疏漏，价值几百万商品就没法售卖。我原以为包材审核很简单，真做起来不是：要审的字段有 60 到 70 项，每项背后是不同国家的政策法规，不同食品有不同的要求。最近一个客户做审核类 Agent，一个品类的审核就有 200 多项需要审核校验的字段，商家要提交六七十份文件，每份提取几百个字段，有些规则能直接判断，还有很多要多跳，ABC 一套组合、ABD 又是另一套，业务专家要梳理好几天才慢慢的齐备。这就是 Agent 到复杂场景落地要跨的一关，背后专业性很强。技术同学做完这样的场景，基本就成了这个领域半个业务专家，从整体逻辑到细节都得懂，才能把它变成 Agent 能力；不懂、边界不清，做出来就上不了线，都是 demo，一遇异常就失效，业务上完全不能接受。

亓隆基：准确率问题，当前只靠大模型解决不了。比如选车，怎么 100% 按业务规则选对：拉冰箱必须直立，因为压缩机，但按长宽高算横着也能放；异形件的摆放规则更多。AI 运营里给运营用的 Agent 要生成营销、价格配置，多是精确计算，只能用工程方式。外呼聊价格、提取价格也可能出错，比如该加 10 块加成 100，在线上就是事故。所以这些都得用 Harness 的方式处理，或者限制住，把确定和不确定的地方定好边界，才可能在线上产生价值。

Agent 的边界到底怎么定？

王仿：面对某个真实业务任务，你们依据什么决定，这一步交给 Agent，那一步交给代码或传统算法，还有一步必须由人处理？

王上淇：分工上还有个现实问题：你做很多工程化，leader 会问你创新点在哪，都上大模型了，为什么流程引擎还是规则？刚才冰箱那个在我看来也是规则。但模型能力其实已经通往 AGI，最新出的国外模型生成代码很牛，因为代码能自闭环；企业里不好，是因为企业权限、企业信息、已知知识模型不知道，比如冰箱必须竖着、审核什么情况 AB、什么情况 CD，这类规则通用模型永远学不到，企业又不太可能微调，我们江苏移动就没有任何微调，让程序员做也难，因为程序员不懂业务。

所以我们现在的做法是：让业务人员通过 AI coding，把确定的、需要规则的业务规则固化成代码，主流程仍然用 AI 串。比如内部派单流程，原来是纯规则引擎编排，现在让业务专家描述规则，AI 生成一段代码，业务人员不用校验代码本身，流程再走时调用这段代码。出了错就判断：是意图识别错了，就去改 Harness 的提示词或补条件；是规则描述对、但生成的代码不对，就让业务部门给测试用例校验后改代码。一轮轮迭代下来，关键环节还是用规则的方式做，只是描述和生成规则用 AI，成本、边界、准确性都解决了，可解释、可撤回、可控也更强。

亓隆基：我们原来也很苦恼哪些用 Agent、哪些用工程。比如用户助手、司机助手，原来在图形界面上点，改成对话方式后，发现在老客身上是左手倒右手，效率反而降低。所以我们认定，Agent 应该用来拓展系统能力，而不是把已有能力重做一遍：把原来做不到的、需要根据当前状态重新思考规划的事，以及萃取出来的业务知识，交给 Agent；而实时交易、规则、传统算法（比如接单概率预测）这些有解的、确定性的问题，还是用最擅长的工具。Agent 更多是把现有能力组合串联，实时思考规划，为业务目标持续努力。

比如 AI 撮合解决的是长尾订单：原来播单给司机，司机十分钟、二十分钟不接，就按规则再播一轮；现在可以根据用户、订单的状态实时规划，用 AI 外呼跟用户、司机商量价格、问他为什么不想接、多少钱能走，收集到足够多司机的意愿再去促成这单。这在没有 Agent 之前只能靠客服或专职人工完成。总结就是，确定有解的问题用工程或机器学习，开放性、需要持续规划决策执行反馈的问题用 Agent。我们做了很多 Agent、花了很多 token，也一直在想额外的业务收益到底是什么，token 账单每月都真实存在，ROI 到底正不正，其实很难回答。所以要把 Agent 用在真正能带来业务收益、提供额外价值的地方。

吕德涛：跟两位不太一样，我们主要是 toC。涉及用户钱包权益的一定放在人这边；自由度高的，比如生成回复、澄清模糊意图、处理长尾表达，可以交给模型。就拿组票来说，最初我们也是用当时最好的模型去组几大几小的门票，本以为没问题，但准确率也就百分之八十左右，最后还是变成模型提需求、用传统的混合整数规划来求解。

王仿：这其实是两套范式、两套技术栈，和深度学习差别很大，适用场景也小。传统推荐系统主要依赖用户行为和交互日志，通过协同过滤、矩阵分解或深度模型优化预测目标；企业 Agent 除了从数据中学习，还要把业务规则、专家知识和工具执行链路显式组织起来。两者面对的问题和工程约束并不完全相同。

我还参观过制造业，他们换耗材，像果链、手机制造里的精密仪器，原来用满一万次就批量换掉，挺浪费；现在结合 Agent 判断健康度，其中传统深度学习负责感知，从图像、数值去判断健康度的波动。以前是人来判断该不该换、是误报还是真的，现在用 Agent 代替人做决策，人工和损耗都降下来了。所以哪些用人、哪些用传统算法、哪些用 Agent，其实没有统一范式，还是要结合具体业务。

那做这种分工设计，什么样的人合适？懂业务的、懂技术的，还是都要懂一些？

亓隆基：前几天某大厂发了一篇文章，说花了无数 token 得出一个关键认知：AI 工程是业产研的工程，不能只靠产研。我们的经验也是这样，真要把业务 Agent 做好，业务、产品、研发都得在，因为只靠产研，你不知道业务策略是什么。就拿 AI 撮合说，怎么跟用户、跟司机打电话，这些策略只有真实客服和一线业务最清楚。所以业产研都要在，而且对技术来说，这比原来做工程项目更有挑战：业务会觉得你做的是最先进的生产力，就该告诉我怎么做最好，而实际上应该是业务和产研一起，把有效的业务策略萃取出来，再让 Agent 遵循执行、拿到结果。

王仿：再把问题收窄。我们常用准确率、置信度来判断能不能上线，但真实业务里有另一个更直接的标准：做错了能不能撤回。可撤回性是不是一个足够通用的边界判据？如果不是，还要加上哪些因素，比如虽然能撤回但恢复成本很高，或者概率很低但后果特别严重？

王上淇：可撤回我们是有要求的，但它不是充分必要条件。尤其是订单，我可以用 AI 下订单，但不能把原来的下单、取消界面删掉，因为再回头跟 AI 说取消已经来不及了。所以现在所有 AI Agent 原有的流程都还在，撤回其实是靠原有 GUI 流程保证的。还有恢复成本，它甚至决定允不允许 AI 操作：比如盖章、审核自动化，本身不复杂，但涉及金额或责任特别重大时，业务人员会觉得哪怕 99% 准确也不让做，恢复成本接受不了。另外可解释、可复现也很重要。深度学习对可解释性要求不高，看指标、看数据就行；但在生产场景里 Agent 是代替人操作的，业务人员不知道它在干什么就接受不了。要能像 Claude 那样一步步告诉你在干什么，不对可以立刻暂停，可暂停、可解释很重要。

亓隆基：还是要看影响面能不能接受。比如 AI 运营改后台的营销、价格配置，即使能撤回，一旦上线就会影响非常多订单，影响不可接受就得在上线前加一道人工审核。我们默认 Agent 保证不了 100% 准确，关键操作上接受不了后果，就必须人工确认。AI 外呼每个版本上线都会做红线检测，看会不会说错话。有些场景可以放松，比如提取金额出错，就通过评测观测资损率，在可控范围内就允许上线。所以最后还是看犯了错、产生的影响能不能接受，能接受多大范围、多大资损，据此决定放行还是人工确认。

吕德涛：我们跟亓老师很像。比如订单日期推荐错，用户要周五、我们推了周六，日期在导购卡片上又不显眼，用户可能直接就付款、还用了优惠券，这时再回撤，权益已经没了，酒店和交通的价格变价又快，好价格就没了，所以特别小心。第二还要看错误用户会不会发现，比如行程规划明显不合理、来回往返同一个景点，或者推荐理由是 A 酒店却挂了 B 酒店的卡，这些都不行。

王仿：所以 toC 更关注用户体验，toB 把安全和责任作为红线，报关出错到底谁扛，Agent 出错会不会影响我的绩效。

观众：Agent 在业务场景里怎么自我优化迭代？

王上淇：分两种。业务场景的优化迭代，现在是找 badcase 分析，判断到底是意图识别错了、工具选错了，还是工具选对了但效果或格式不符预期：意图识别错就改提示词或换模型，工具调用错就评估是描述不准还是工具太多要删减，说白了就是要么改、要么换模型、要么改 Harness 的配套。另一块我们做 MAS 平台、AI 观测和 AI 稳定性，还在探索。现在 70% 的智能体优化还是人工的，业界有一些偏自动的方式，通过 trace 去优化 harness 或 skills，说实话在生产场景效果不好、也不可控，但在通用场景还可以。

所谓通用场景，就是比如 OpenClaw 很火、移动也做一个内部版本给员工用，各部门搞出各种 skills，处理文档、处理投诉。之前拿开源的 Harness 改了改准确率不高，领导要求准确率、不能有投诉、还得有评估标准，我们就想用调用链来评估，比如超过 20 步的技能，让大模型根据 trace 自动分析是 skill 生成得不好还是提示词不好，再动态优化。这种偏泛化的通用场景里有用，能把步数从普遍超过 20 步、耗时十几分钟，平均降到 15 步以内，大概提升四分之一效率；准确性不好评估，就看重复生成率有没有下降。所以专一的业务场景还是靠人评估、靠测试集，通用场景可以试 trace 自动化。

亓隆基：我们的经验是有两个闭环。外环是业务指标的 loop。比如 AI 撮合解决订单配对，环节很多、各有转化漏斗，得先有业务指标体系，确保在解决正确的问题：先找到正确的司机，再用 AI 外呼，靠话术 SOP、指令遵循、Agent 能力去跟用户聊，最后成单；中间还有外呼线路的触达率、接通率。外环就是确保能找到掉点的环节和正确的做功方向，接通率上不去，Agent 再强也没收益。内环是 Agent 本身能力的闭环。AI 外呼是开放式的，就要靠可观测性记录全过程，看每个环节的意图识别、ASR、回复是否正确，很多时候要人工标注，业内会用 LLM as a Judge 加速，也可以用更高级的模型来标注，省掉大量人力。另外还可以用大模型去萃取金牌销冠的话术和策略，加速业务知识萃取。所以要迭代 Agent，两个闭环都得做好：业务指标体系定好，明确 Agent 在哪个方向做功；Agent 自身能力上，话术和业务策略有没有被遵循、badcase 率有没有降下来。

吕德涛：一是评测一定要做准，我们线上入库标准一部分靠强代码校验、一部分靠价值模型，评测不准，自进化的方向就错了，所以要在评测上下功夫。二是准备一份线上的黄金数据集，叫 metadata，每次迭代都在上面做回测，保证修改是准的，因为自进化很容易 hacking，模型很容易偷懒。

王仿：核心是要有一个可学习的目标。亓老师讲的，我得知道我学的是金牌客服、金牌销售的逻辑，这个 tag 在哪；还得圈定这个 tag 下是什么场景、用什么策略。自进化就得有这么一套反馈逻辑，包括吕老师说的拿金标准做离线回测。先定义好问题，语料丰富了，Agent 的自我学习反馈能力会越来越强，再和线上指标挂钩。我过去在客服场景这么做过，很有效：离线挖掘能发现，金牌客服在人问优惠条件时，会讲怎么用优惠、再用产品卖点击中他，影响他的决策；因为你已经有大量转化和未转化的结果，未转化的往往是人问啥答啥、很泛、转化率很低。

Agent 应该拥有多少自主权？

王仿：现在行业里很喜欢谈 Autonomous Agent，好像越能自主规划、调用工具、完成长任务就越先进。但到了生产环境，真实业务里的 Agent 真的是越自主越好吗？

亓隆基：我有两个反例。第一个是下单，我们试过完全 agentic，把上下文、目标、可调用的工具都给模型，让它自主决定怎么跟用户交互，结果回收回来比原来定好的流程还差。因为在明确业务场景下，AI 会输出非常多内容，提问只花几秒，读懂却要很久；自主时它给用户太多选择，但明确的用户只想省心，你直接告诉他选什么车、什么价就行。你自己用 AI 也这样，做 PPT 只想让它快点做好，不想讨论半天。第二个是 AI 调度，同样是 agentic，把目标、上下文、工具都交给它自己决定怎么跟用户和司机聊，问题是路径不可控：最后有效了，也不知道它用的什么策略，就没法持续优化，来了新策略也没法让它遵循去回收效果，从策略到执行到结果的关系被打断了。所以关键节点需要确定性，只在需要模型自主发挥的环节让它自主。

吕德涛：生产环境里 Agent 要有明确的界限和责任，即使没到 100%、也要 99% 以上才行，否则对 C 端就是很大的伤害。它可以在决策空间里灵活，比如调用各种工具；但输出给 C 端的回复要谨慎，组票、实时价格、库存、商品 ID、订单状态都不能错，错了不是舆情就是资损。

王上淇：换个角度想，自主和失控的区别是什么？我理解自主是在有限规则下发挥最大潜力，失控是不按规则来。我们为什么要聊自主性？如果任务本来就很 work，那也需要 Agent，但绝不需要它越来越自主；自主性是用来解决原来解决不了的问题的。所以自主性的上限，就是你希望它解决问题的灵活度，但要有门槛，没门槛就是失控。门槛从技术上很简单：允许你调用工具，但能调哪些由我定，你的自主权只在于自己选调哪个，门槛就是我配 10 个还是 20 个工具。

这里还延伸出一个问题，原来的编程叫可信编程，现在通用编程叫不可信编程，因为它会写代码：给了它 10 个工具，它觉得完不成但还是硬做，就自己写代码去实现，事情就又不可控了，所以大家都要做沙箱。另外，为什么自主不够好？因为 99% 的厂商没有能力基于它的行为或错误去提升：agentic 的提升方案很少、harness 又复杂，甚至找不到问题在哪，因为大部分业务场景没法把数据收回来做强化学习，成本太高。未来如果有企业能这么做，自主性才可能越来越高，否则一定被限制在门槛里，不然就是失控。

王仿：相比推荐、广告等已经形成成熟反馈闭环的系统，企业 Agent 的优化链路还不够标准化。虽然已经可以通过轨迹分析、离线评测和反馈数据迭代，但要做到可归因、可控风险地持续提升，目前仍然很难，也缺少可广泛复用的生产范式。

展望未来

王仿：未来真正有价值的企业 Agent，核心竞争力到底是什么？

亓隆基：模型是起点，基座模型大家都能选，选个好模型起点就高一些。到了业务上，第一步是 Harness，用工程把确定和不确定的边界分清：需要思考规划的交给模型，需要确定的交给工程，再把机器学习算法、运筹优化这些工具综合进来，这是企业 Agent 的下限。下限之上，靠业务 loop 和 Agent 能力 loop 这两个闭环持续提升。上限则像做工程一样，一个业务系统好不好，最后不在于基础设施，而在于对业务知识的萃取和业务架构的设计，它决定了系统能支持业务五到十年，还是每年都要大重构。类比到 Agent，上限就在于能萃取多少业务知识、找到什么场景和做功方向。所以就是模型决定起点，Harness 决定下限，双 Loop 决定方向，加上业务知识萃取到什么程度、在哪个环节做功，决定了上限。

王上淇：企业 Agent 是我自己打造一个，还是我帮别的企业打造，核心竞争力和壁垒是不一样的。对我们来说，怎么快速把企业能力对接上就是个大困难，我们做过 MCP、Skills（可能还不算协议类型）、AGUI 这些规范，但把存量系统接进 Agent 都很难。数据萃取这点我非常赞同，没有数据、没有数据萃取的企业 Agent 就没有意义。企业生产场景最大的问题是，规则和业务数据大多沉淀在原有系统里。像移动，还有中石油等等，我们都做过一些服务，你想给企业做诊断会发现很难，因为拿不到、也接不上它的系统。所以怎么用相对通用的方式，把信息化不好的企业的能力梳理、暴露出来，变成一个能快速接入的平台，是未来的关键。

之前很火的 Palantir 做数据业务建模，很早就有了，但能力释放不出来，梳理好了数据、有了平台，也用不起来，直到有了大模型才有人能去用。现在大部分企业缺的就是这样一个 Palantir 式的平台，能把数据资产自动化地萃取出来。另外还有一点，企业内部关键是怎么平衡管理和智能体本身：企业 Agent 能不能承载职责和流程。我们现在不只做业务 Agent，还把智能体和原有业务流程挂钩，流程对应原来的责任，比如智能批文、审核都要求智能体跟流程对应，才能保证责任和权限清晰。所以一方面是萃取企业能力数据的能力，一方面是把 Agent 和流程关联的能力，都建立在足够强的 Harness、loop 和数据能力之上。

吕德涛：旅行是一个相对垂类的行业。我觉得未来企业 Agent 的核心竞争力，还是垂类领域的行业供给和行业知识，能不能变成可执行、可验证、可迭代的系统能力。比如行程规划，调基模就能产生一份不错的行程，但难的是它能不能真的走得通：景点之间的距离、交通、营业时间能不能衔接上，还要考虑每天游玩的强度，景点在现实中得真实存在。行程往下就是买酒店、买门票，价格库存必须来自真实业务系统，组出来的票要符合真实出行需求，进订单还要用户确认，这些都不是模型自由发挥能生成的。模型适合理解偏好、筛选景点、生成方案，地图路线营业时间可以用工具取，票的组合可以用确定性算法，但价格和库存必须由业务系统提供。所以企业 Agent 的壁垒，不是生成一份看起来不错的答案，而是企业自己的数据、工具、算法、业务规则、评测体系在真实世界里能不能成立。

王仿：这有点像世界模型，在真实世界里到底 work 不 work。过去两年我们一直在讨论怎么让 Agent 更聪明、做更多事；但 Agent 真正进生产之后，另一个问题越来越重要：我们到底允许 Agent 做什么，哪些必须由人来做？

热度延续：12 月 AICon 北京站见

跳转微信打开