" 机器正在成为思考的主力，智能正在成为一种规模化的商品。" 阿里巴巴集团 CEO 吴泳铭在 2026 云栖大会上做出判断：他指出，未来机器思考的总量将是人类的 1000 倍，但真正定义时代的 AI 产品，至今还没有出现。
智能能够被规模化供应，距离企业放心使用它，还有一段路，当前的 Agent 能力到最终愿景之间，还有巨大的工程鸿沟需要跨越。
模型可以完成越来越复杂的推理，企业却需要确认，这些判断能否支撑真实业务中的每一次行动。因为企业在把任务交给 Agent 的那一刻，也交出了一部分决策权。
以往，一套业务软件执行什么操作，通常有预先写好的流程，关键节点由人确认。Agent 接到一个目标后，可以自行拆解任务，选择工具，根据执行结果调整下一步。
企业看重的是这种自主性，但当它调用的接口连接着真实交易，读取的数据涉及客户信息，一个看似合理的判断，就可能产生难以撤回的后果。
这让企业陷入一种新的两难。流程规定得太细，Agent 施展能力的空间有限，团队还要维护大量规则；放宽限制，如果系统出了差错，谁能及时发现，并把它停在造成损失之前。
模型能力越强，这个问题就越迫切。因为企业能够交给 Agent 的任务更多了，任务之间的联系也更复杂了。Agent 让企业看到替代繁琐工作的希望，却无法替技术负责人回答长期运行的账怎么算，原有系统承受得住多少调用，以及业务部门究竟愿意信任它到什么程度。
在云栖大会企业级 Agent 实践峰会上，众多企业谈到了这些具体的难处。它们已经投入资源，也把部分 Agent 放进了真实业务，此时最有价值的经验，往往藏在演示不容易呈现的地方，上线后暴露的故障，为修复问题积累的工程负担，以及技术指标改善、业务结果却没有同步变化的困惑。
综合来看，Agent 的自主性，反而提高了企业对基础设施和治理的要求。任务可以动态执行，身份与权限却不能含糊；模型可以持续升级，业务运行不能随之失去稳定性。原有 IT 体系中的一些问题被放大了，也有一些能力需要重新建设。
企业与云平台的分工，便落在这些要求之中。公共底座能承接多少复杂性，企业又必须掌握哪些业务判断，这决定了 Agent 能否接住下一项更重要的任务。
理解需求之后，还有一条执行链路
企业任务很少像演示中的指令那样完整。满帮的司机找货时，可能先提出回南京的目标，看到候选货源后，再补充价格要求。新的信息随时会进来，司机也可能改变主意，Agent 必须记住已经确认的条件，理解后续要求与它们的关系，并据此继续行动。
满帮曾尝试用意图识别增加系统的确定性，再由主 Agent 分发子任务，但真实对话里，一句话往往同时包含问答和执行要求，也可能附带议价条件，简单的分类会丢失这些关系，限制模型理解业务的能力。
接口同样需要重新适配，满帮集团 AI 算法总监高艺铭举例，传统系统返回一个编号为 219 的错误，Agent 很难判断下一步该做什么。如果反馈明确告知缺少车长，并提供合理的参数建议，它才有机会补全信息，继续执行。
这些非常琐碎的问题，却决定了任务能否完成。工具的用途需要描述清楚，参数要经过校验，失败要有可执行的反馈，涉及交易的动作，还必须检查授权和业务条件，模型给出一个合理判断之后，企业需要有一套机制，将这个判断放进可靠的执行过程。
Harness 工程承担的就是其中相当一部分工作，它负责组织模型周围的上下文与工具，管理任务状态，约束执行，并处理失败恢复。技术团队既要给模型足够的信息和行动空间，也要让整个过程保持可控。
困难在于，这套工程本身也会变得复杂。满帮上线后每天收到大量失败案例，团队希望尽快修复，于是不断修改代码和技能，补充提示词。一些局部问题解决了，系统内部却积累了越来越多的特殊处理。
高艺铭提到，团队早期自建的评测体系曾在达到一定分数后难以继续提升，系统债是重要原因。逐个修补眼前的问题，很容易挤占对整体架构的维护，更换模型时，这些补丁还可能阻碍新能力发挥作用。
因此，团队需要知道问题究竟出在哪里，比如，模型没有理解任务，与工具参数传错，是两类不同的故障，业务规则缺失，也不能一直依靠提示词补偿，归因足够准确，工程投入才不会变成不断叠加的特殊情况。
满帮为此保留了自研的业务标注和归因系统 Vertex，同时使用云上的 AgentLoop 承接通用观测与评测，紧贴业务的部分需要高频调整，通用工程能力则可以借助平台减少重复建设。
由此可见，企业掌握业务规则和任务标准，云平台提供运行与治理支撑，双方的能力需要在执行链路中配合，才能把模型的判断转化为可靠的业务动作。
数据很多，Agent 未必懂业务
企业知识库接通之后，Agent 仍可能犯一些业内人士看来很基础的错误。
在满帮的货运场景中，司机使用的标箱一词，指的是运输标准集装箱的平板车。通用模型却可能将它理解为厢式货车，这类行业知识大量存在于线下交流，未必有充足的公开材料可供模型学习。
补足知识是必要的，但把企业全部文档放进上下文，效果也未必好。满帮清理材料时发现，有些内容并不能提供帮助。例如，文档中泛化的议价技巧，不一定比模型已有的理解更有效，多余信息进入上下文后，还可能干扰任务执行，团队需要辨认哪些知识是模型欠缺的，哪些又真正影响当前决策。
这项工作很难只靠技术团队完成，业务专家需要判断知识是否准确，使用者需要反馈它是否有效，系统还要保留更新和纠错的渠道。
贝壳面对的问题更复杂一些。房产咨询涉及预算与通勤，也涉及家庭结构和居住偏好，用户很难在第一次交流时说明全部要求，条件之间还经常存在冲突。Agent 给出候选房源后，需要继续解释差异，帮助用户权衡，并记住沟通中已经确认的取舍。
贝壳首席算法科学家尹俊希在分享中强调，对人的理解与对房的理解需要结合，房源信息不能孤立存在，它要与所在小区和区域资源联系起来，也要放进用户具体的生活需求中分析。
因此，Agent 使用的数据，不只是等待检索的文本。它还包括关系和状态，以及任务必须遵守的约束，预算等硬条件需要持续保留，用户尚未确定的偏好则需要通过交互逐步澄清，模型不能在几轮对话后遗忘已经确认的限制，也不能把推测当成事实。
贝壳介绍的工程框架，将上下文管理与状态管理分别纳入设计，并记录工具调用和中间决策，这些安排让团队有机会检查错误发生在哪个环节，判断是信息没有召回，还是模型使用信息的方式出了问题。
易方达基金首席信息官刘硕凌博士分享的数据治理实践提供了另一种观察。对金融机构而言，一项数据能被找到，还不足以直接进入分析，指标口径需要明确，来源需要可靠，权限也必须保留，数据经过专业语义和质量治理，才能成为 AI 可检索和调用的资产。
平台可以提供共用的数据治理能力，具体业务口径必须要专业人员参与定义。模型更新之后，这些经过整理的语义和规则仍然可以复用，企业不必每次重新解释自己的业务。
云上的存储与检索服务，以及记忆和模型能力，为这些工作提供了基础。企业真正需要投入的，是把散落在文档和系统中的知识组织起来，让它们在适当的任务条件下参与判断，并能随着业务变化得到修正。
能够执行，不等于拥有权限
Agent 接入的工具越多，权限问题就越难回避。
一次对话可能跨越多个业务系统。Agent 需要读取资料，调用接口，再将结果写回。每一步都涉及身份，前一次访问成功，也不能自动成为下一次操作的授权。
易方达允许接入不同 Agent 框架，但设备身份和访问凭证的管理，以及操作日志的记录，都需遵循统一要求。具体而言，统一入口负责设备认证和代理访问，同时管理 Token 与审计日志。业务系统仍保留自身权限控制，高风险操作须由人工复核，防止局部授权扩大至整条执行链路。
这与金融业务的使用方式有关，Agent 可以帮助研究员处理更多材料，专业分析需要核查数据口径，区分事实与判断，并能回到原始来源复核，信息不充分时如何取舍，也涉及人的责任。
众阳健康科技集团产品研发中心总经理郭龙领表达了相似的要求，医疗场景容错低，医疗 Agent 需可解释，可管控并具备人工接管能力。跨医院部署需妥善解决医生授权、患者信息安全保护等基础设施建设，完善好基础设施建设才能做好规模化落地。
权限边界有时会出现在更日常的场景中。
阿里云的 Patrick 管理者分身，是阿里云内部为阿里云智能集团资深副总裁、公共云事业部总裁刘伟光构建的一个 AI 数字员工，拥有独立工号和钉钉账号。从刘伟光过往的会议记录、发言稿和业务决策中提取表达习惯与判断经验，让它能够结合这些信息与团队交流，并承担催办、跟进、记录和信息汇总等工作。
Patrick 管理者分身，需要学习管理者的工作方式，但不能直接使用管理者本人的账号。否则，普通员工向分身提问，就可能间接触达自己无权访问的信息。
团队为它设置了独立身份，调用工具时，要核验实际对话者的身份，并在后续链路中沿用相应权限，分身可以提供建议，访问数据的范围仍由权限体系约束。
安全设计因此需要进入任务的每一个关键节点，身份决定访问范围，沙箱限制执行环境，审计留下记录，人工复核处理高风险动作。出了问题，还要能够中断任务，找到责任环节。
云平台提供的网关与沙箱等能力，可以帮助企业建立这些防线。但哪些动作风险高，什么情况下必须由人确认，最终还要由业务规则决定，技术控制与责任安排需要对应起来，Agent 才能获得明确的行动空间。
Agent 规模化，量变到质变
满帮的一次扩量经历颇有代表性。据高艺铭介绍，第一次扩展到约 2000 个 Agent 时，线上生产系统就受到了冲击，这个系统原本能够承载几百万用户，却没有适应 Agent 的请求方式。
人使用产品时，操作之间存在间隔，Agent 可以连续调用大量接口，还可能在用户离线后继续运行，一个任务的执行频率，与一个用户的访问频率，差别很大。
只按在线数量估算规模，容易低估负载，团队还需要计算单个任务会调用多少次工具，失败后如何重试，以及某个事件会同时唤醒多少任务，异常循环和重复调用，会把压力继续放大。
因此，满帮采用了两套生产系统通过桥接层协同的结构，传统系统负责货源发布和撮合下单等业务，继续保证确定性流程的稳定。Agent 系统处理目标理解和持续执行，桥接层则负责工具适配与鉴权，并配合安全控制和数据交互。
这也说明，企业现有系统仍有不可取代的价值，原有生产系统已经积累了稳定性机制，Agent 需要接入这些能力，同时避免把自身的不确定性直接传递给交易和履约。
运行方式也需要调整，全天候可服务，不要求所有任务一直占用计算资源。状态持久化让任务可以暂停后恢复，事件触发让系统按需唤醒，限流与超时控制则避免局部故障扩大。
多 Agent 协作还会增加一层复杂度，如果几个 Agent 共同服务一个用户，它们需要知道需求是否更新，其他参与者完成了什么，以及失败之后由谁继续处理。状态不同步，可能造成重复操作，也可能让后续步骤建立在错误信息之上。
这些问题与企业熟悉的分布式系统工程有联系，但负载和执行方式有了新的特点。模型服务的延迟会影响任务链，工具故障可能触发新的推理和重试，运行成本也会随着路径变化而波动。
满帮介绍，其整体系统使用阿里云提供的模型服务和算力设施，并借助记忆与治理能力支撑运行，底层各项服务需要相互配合，单独增加某一类资源，很难解决整条链路的问题。
规模化的工程准备，需要在扩量之前完成。任务状态怎样保存，接口如何保护，故障怎么恢复，这些问题在演示里不显眼，却决定生产系统能承受多少真实负载。
Agent 持续运行，该如何算好 ROI 这笔账。
小红书质效 &AI 应用总架构师飞鸿提到，除了技术优化，企业还需要把 AI 成本归属到具体经营单元。费用由技术团队统一承担时，容易只看到总账，拆到实际业务之后，才有机会讨论哪些投入有价值，哪些场景值得继续扩大。
不过，账目归属只是第一步，企业还需要看清资源消耗与工作结果之间的关系。调用量增加，可能是任务更多，也可能是执行效率下降。
阿里云强调了完整执行轨迹的作用，基础指标能够反映吞吐和延迟，轨迹则能显示任务经过了哪些步骤，重复调用发生在哪里，某次失败为何引发多轮重试，都需要沿链路检查。
结果评估还要回到业务之中，满帮在实践中发现，技术指标与用户留存之间的关系会随阶段变化。初期提高回复和执行的正确率，能够改善体验；达到一定水平后，继续优化同一个指标，未必带来相同的业务收益。
这使评测成为一项持续工作，标准要根据业务目标制定，样本要覆盖真实任务，评测结果还需要与专业人员的判断校准。
成本优化也应建立在这个基础上。小红书分享了模型路由和上下文管理等方法，简单任务分配给合适的模型，减少不必要的高成本调用。据悉，模型路由相关实践上线后，成本下降约 69%。
满帮方面，部分适配较好的 Agent，成本降至此前约四分之一；另一些 Agent 没有获得降本收益，准确率还下降了。这说明，模型变强之后，原有补丁和执行逻辑是否仍然合适，需要重新验证。
众阳健康对成本管控设定了明确约束：固定规则交由工具执行，通用知识做摘要与缓存，按任务复杂度分级调度模型。所有参数调整均需核验业务质量，不可为降低 Token 消耗，牺牲系统安全与诊疗指标。
这些实践共同构成了一套运营过程。先定义任务成功的标准，再记录执行，找出问题，提出改进，最后通过实验和灰度发布验证效果，每一步都需要证据，不能只凭一次看起来不错的回答判断。
执行轨迹还有进一步使用的可能。基元律动联合创始人兼 CTO 韩凯介绍，其通过隔离环境生成任务轨迹，经过结构与语义评估筛选，再用于模型后训练，训练后的模型重新进入 Harness 接受验证，形成下一轮改进的数据来源。
但日志并不会自动变成高质量训练材料，数据准入和评测同样重要，云平台可以承接观测与训练设施，企业决定什么样的结果值得学习，什么样的改动允许上线。
Agent 的经营价值，也需要在这种持续检查中得到确认。
数字员工多了，谁来管理
据阿里云公共云事业部 AIX 技术负责人施磊介绍，两三个月内，公共云事业部已有 60 多个具备独立工号的 Agent。部分服务于管理者，另一些承担具体岗位中的常规任务。
数量增加之后，管理问题很快出现。不同团队可能建设相似的能力，单个数字员工不断增加技能，职责越来越宽，却很少与其他数字员工交流，局部看是在满足需求，放到组织层面，则可能形成重复建设。
阿里云内部为此引入了上岗审批规则，数字员工需要说明负责的工作，由业务负责人和 HR 一起审核。岗位职责写清楚之后，组织才知道它与现有人员如何配合，哪些事情不应交给它。
协作也需要相应设施，每个数字员工维护自己的岗位说明，遇到超出自身能力的任务时，可以根据职责寻找合适的协作者。
这类安排与单纯的任务编排有所不同，企业不仅要决定某一步由哪个 Agent 执行，还要有人负责维护它的知识，检查它的表现，并处理职责重叠和异常情况。
销售运营团队的变化体现了这一点，常规问题和部分稳定流程交给数字员工之后，运营人员需要持续更新知识与技能，同时处理更复杂的业务。Agent 的工作效果，依赖这些维护投入。
知识回流也是阿里云团队探索的方向，数字员工参与工作时接触到新的信息和经验，经过治理后，可以供其他成员使用，这个过程需要检查信息是否准确，以及能否共享，不能把每次对话都直接当成组织知识。
数字员工因而需要完整的管理安排——独立身份解决账号问题，岗位说明明确职责，审批控制设立，运行记录支持检查，它们共同决定这支队伍能否被有效使用。
阿里云内部的实践探索出一条新路，对计划扩大 Agent 使用范围的企业而言，每增加一个数字员工，组织也需要明确谁负责让它持续胜任工作。
给 AI 花的钱，企业能沉淀什么
如果要用一个准确的描述来形容当下的企业 AI 现状，" 一片混乱的欣欣向荣 "，可能十分贴切，企业探索使用 AI 的方式和节奏，已经很难用一种统一部署方式概括，各自发散，尚未收敛。
有的依托云平台开发业务 Agent，有的同时使用云上与本地资源，有的由模型厂商提供服务。直接采用现成应用，也不代表完全省去集成和治理，建设路径不同，通用工程能力与企业自有能力之间的分工也不同。
全栈 AI 云的价值，在于让这些公共能力更容易组合和复用。企业可以按自身条件选择现成应用，也可以在平台上构建专有能力，不必为每个项目重新搭建一套基础设施。
平台接入与业务成熟之间，仍有具体工作要完成。CTO/CIO/ 技术负责人需要掌握的，是企业自身不能外包出去的认知。业务目标如何定义，哪些知识可信，哪些动作必须复核，以及什么样的结果值得继续投入，都需要企业自己给出答案。
模型会更新，框架也可能替换，经过业务验证的规则与技能，能够复用的评测样本，以及清楚的责任安排，可以在迭代中保留下来。
这需要企业与云平台各自做好自己的工作。公共底座承担通用工程的复杂性，企业持续打磨专业能力，两者之间形成稳定的协作，技术更新才不至于总伴随着推倒重来。对于更多缺乏完整 AI 研发团队的行业企业，这种分工也关系到它们能否承担持续建设的成本，让 Agent 真正留在业务里。
眼下的探索还会有反复，有些应用会被淘汰，有些投入也未必达到预期。但判断一笔 AI 投入的价值，可以多看一层，项目结束或工具替换之后，企业是否更理解自己的业务，是否留下了更可靠的数据和方法，是否具备解决下一类问题的能力。
当这样的机制真正运转起来，Agent 带来的收益就有机会超出单个岗位的提效。企业每完成一项工作，都可能为下一项工作留下更好的基础，千行百业对 AI 的投入，也才能逐渐沉淀为各自可持续的生产能力。
正如吴泳铭所说：" 把繁重的任务留给机器，把时间、创造力以及对美好事物的感受留给人类。" 这一切，才刚刚开始。（本文首发于钛媒体 APP）
