在大模型快速演进的今天，企业正面对一个现实问题。模型可以流畅回答通用问题，但进入复杂业务后，从给出答案到办成一件事，中间仍有距离。一些企业投入建设的 Agent 平台，在业务推广时遇到知识、流程和系统接入的困难。企业级Agent如何真正变成“生产力”？
在10月30-31日举办的Agentic AICon大会上，网易智企·云商AI DESK业务负责人 李城带来了以《AI DESK 数字员工平台：从技术探索到业务闭环》为主题的演讲分享，深度拆解了企业级 Agent 在知识工程、执行范式、端到端 UI 交互、人机协同等维度的核心破局路径。

他的一个重要判断是，企业 AI 的规模化落地，需要将稀缺前沿部署工程师的个人经验，逐步转成可复用的工程体系。

01 / 普遍痛点

大模型能力很强，为什么企业业务还跑不起来？

这两年大家都在做 Agent 落地，但真正进入企业场景时，我们发现有几个常见卡点。

“给答案”与“办成事”之间的鸿沟

模型能回答通用规则，但企业用户要的是“办理闭环”。比如保险用户问“我的保单到期了吗？”，背后隐藏着身份核验、保单查询、合规校验、退款发起等一系列动作，单纯的对话无法交付业务结果。

缺乏私域上下文

企业有独特的组织架构、CRM、订单系统、条款及安全规范。模型智商再高，不做业务输入与系统连通，就像新员工不经培训直接上岗。

技术范式快速迭代带来的“系统过时”

去年很多企业自建了基于传统“意图识别 + 固定工作流”的 Agent，今年业务一推就发现推不动——底层架构已经落后于当前的 Agent 技术范式。

业务到技术的翻译成本过高（FDE 门槛高）

如何将业务复杂的边界、异常、权限转化为模型可理解、可调度的技术语言，成为落地瓶颈。

这些问题延续了网易智企·云商在企业服务中的实践。从2016年的七鱼智能客服，到服务营销能力，再到 AI Desk 平台，我们一直在面对具体的客户服务和业务处理要求。

因此，AI Desk 产品在立项时就重视两个选择：

  • 支持企业环境内的私有化部署，在企业的授权与管控下连接核心系统、数据和知识。
  • 坚持产品化订阅与持续升级，让后续技术和业务变化能够进入产品服务过程。

02 / AI DESK怎样支持企业级任务执行？

如何让 Agent 具备“企业级确定性”

企业级 Agent 需要在安全围栏、权限和审计要求下运行。模型提出了一个动作，并不意味着它已经获得执行权限。

在我们的设计里，可以从三个层次理解它的运行方式。

Agent Studio 编排层

通过 Agent Profile 定义任务能力，配置知识、记忆、Skill 和工具，以及相应业务规程。

Agent Runtime 执行层

由自研统一运行内核组织当前任务的上下文，调用业务能力，推进任务并核验结果。

统一运行与管控层

我们在演讲中将这一层类比为 Agent OS。它承担资源调度和状态管理，配合权限控制、记录留存等运行保障。

基于此架构，一个典型的企业业务流程（如保单办理）会被拆解为五大标准闭环：

  • 身份识别：接入 CRM 等业务系统，自动识别提问者身份与名下资产；
  • 合规核对：根据产品条款与理赔规则进行多维度条件校验；
  • 推理决策：基于完整上下文，大模型推理下一步行动路径并进行必要的追问澄清；
  • 执行办理：通过安全接口进行业务实操；
  • 审计反馈：记录每一步推理链条与执行日志，实现 100% 可追溯。

03 / 深水区破局

知识、执行与交互需要一起进入业务流程

知识工程，怎样支撑复杂问题？

我们在实施中看到，知识经常是企业落地 Agent 的第一道门槛。文档上传之后，还要让 Agent 能够找到、理解并核对任务所需的依据。

演讲里展示过一个保险业务人员的真实提问。一位持内地身份、准备来港投保的女性客户，需要提交哪些文件？如果她的丈夫同时承担相关保单角色，材料要求又是什么？

这个问题包含产品、身份、年龄和人员关系等条件。只召回一段语义相近的文字，可能覆盖不了全部要求。

我们对同一批知识采用了三种组织方式。

  • RAG 切片，用于从文档中定位相关段落、说明和制度条款。

  • GraphRAG 知识图谱，用于表达实体及关系，支持追查关联条件。

  • Wiki 主题页面，将相关知识组织成目录、属性和常见问法，帮助理解复杂主题。

Search Agent 接到问题后，会拆出待核实事项，再按问题选择检索来源。召回之后，需要精读原文，检查每个待确认项是否有依据；存在缺口时，再补充检索。

摘要帮助发现信息，原文支撑最终结论。 检索的来源和循环次数，也要根据任务配置，并非每次都必须三路同时召回。

执行分工，为什么要引入 AOP？

在复杂业务中，我们尝试过将一个子场景交给一个 Skill。开始看起来很简洁，但随着实施推进，异常分支越来越多，还需要调用不同接口， Skill 就逐渐变重。

预先画定的大型流程，同样会遇到维护问题。真实业务存在澄清、补件和临时岔开的情况，把所有可能性都穷举出来，并不容易。

我们因此设计了 AOP，也就是 Agent 作业规程。

在这套分工中，Skill 负责意图理解、规划和任务推进， AOP 组织需要按规则执行的业务步骤。

企业可以将相对独立的处理过程定义为规程。任务执行到某一步，可以等待用户补充，转入人工处理，或者根据保存的状态继续。执行细节由代码节点管理，减少把整段流程说明持续放进模型上下文的需要。

这是一种职责划分和工程设计。权限校验、异常处理及执行结果核验，仍然需要在具体任务中落实。

对话内业务卡片，让用户接着办

如果办理业务只能不断输入文字，用户体验也会受到影响。选择保单、验证身份、填写账户，这些动作可以采用更合适的交互方式。

AI Desk 在 A2UI 相关协议基础上封装业务组件，通过结构化卡片承接办理。我们将这种对话内交互形象地称为“AI 小程序”。

在满期预登记演示中，用户可以在会话里选择保单，确认收款币种和方式，补充银行账户与证明材料，并完成必要的身份验证和确认，随后提交申请。

对话负责沟通，卡片承接填写和确认，再与业务流程接续。用户可以在当前会话中推进申请，后续审核与处理进度仍以业务系统为准。

人机协作，让复杂问题接得住

Agent 参与执行之后，企业仍然需要明确谁承担决策责任。

有些场景由人工接待， AI 提供知识与处理建议。另一些场景由 Agent 推进，在高风险动作或例外判断处申请人工协助。遇到复杂问题，也可以由人工接管。

例如退款， Agent 可以先收集材料并核对信息，但是否通过、是否调整金额，需要按业务规则交给人工确认。申请协助时，应当汇总已查信息和当前进度，减少用户和员工重新说明的负担。

保留原有系统，也能加装 AI

企业已有的 CRM、工单或呼叫系统，往往已经运行多年。客户会问，能否保留这些系统，增加 AI 能力？

我们实际推进的场景包括在线会话辅助、工单起草，以及接入既有 ASR 转写后的呼入应答辅助。销售也可以结合 CRM 中的客户资料、跟进记录和商机阶段，获得拜访前的沟通建议。

这里需要解决实际的接口、权限与结果回写条件。 AI 负责分析和起草，业务人员按规则确认执行，原有系统继续承担相应业务职责。

04 / 一线复盘

从一线的交付经验，走向工程化体系

FDE 的一项重要工作，是将复杂业务诉求转成可运行的 Agent 场景。这需要深入业务，也需要理解技术边界。

我们的实施通常从业务调研开始，问清主流程、异常和人工介入条件，再设计 Agent、 Skill、 AOP 与卡片如何配合。之后进行知识工程和场景实施，完成配置与接口联调，并通过评测验证。

一线实施给了我们几个很具体的经验。

一个 Skill 包下全部职责，会越做越重

最初只想处理一个子场景，后来却不断加进异常和接口。随着内容增长，模型需要遵循的指令也会变多。

我们因此拆分职责，让 Skill 处理理解和规划，将特定执行过程交给 AOP 管理。拆分方式要结合业务，并非 Skill 越多越好。

接口能通，还需要适配上下文

企业原有接口服务于既定系统，返回内容未必都与 Agent 当前任务有关。把大量无关字段直接放进上下文，会增加处理负担。

因此，工具接入需要支持前后置处理，整理参数，并裁剪返回结果，只保留任务需要的信息。这类共性要求，会回到产品中，成为可复用能力。

调好一个场景，还要回归其他场景

多个 Agent 共用 Skill 或者工具时，修改场景 A，可能影响场景 B。调优需要建立评测基线，覆盖正常、异常和边界情况，每次修改后做回归检查。

上线也只是一个阶段。用户反馈和人工纠正应当进入分析，找到知识、 Skill 或规程中的问题。修正后重新评测，确认没有影响原有场景，再进入后续业务。

一次服务留下经验，还要经过验证，才能成为下一次任务可复用的能力。

这些现场经验有两个产品化出口。通用的能力改进回到 AI Desk 产品，实施方法、配置与验证经验则进入配套的 DeskOps 交付平台。

既理解垂直业务又精通 AI 的人才很稀缺。我们希望逐步降低对少数 FDE 个体经验的依赖，把现场方法转成可复用的 Engineering 工程体系。

AI Desk 希望实现的，就是让数字员工在企业里真正上岗，参与实际业务工作。

05 / 现场精彩 QA

三个现场问题，继续拆解工程边界

Q1：技能（Skill）粒度如果划得太细，意图容易匹配不准；划得太粗，模型执行又不到位，如何权衡？

李城：这正是我们研发 AOP 的核心原因。靠纯 Skill 无法完美解决复杂场景。目前业界最合理的方案是：让 Skill 专注于意图理解与宏观流程规划，真正的工具调用、多接口串联、异常处理全部下沉到 AOP 代码节点中。这样既保证了灵活性，又消除了大模型上下文负担。

Q2：现在 Skill 内部也可以放脚本（Script），AOP 与普通脚本调用的最大区别是什么？

李城：最大区别在于可维护性、跨场景复用与可中断跳转能力。第一，如果一个确定性流程有 20 个节点，写在脚本里必须一次性走完；而 AOP 支持按需随时跳入、跳出与挂起。第二，很多底层的办理逻辑（如退保、身份核验）是跨业务场景公用的，AOP 可以作为独立资产被多个 Agent 共享，避免在每个 Skill 里重复编写。

Q3：三模态知识库通过 Search Agent Loop 循环检索，如何平衡检索准确率与响应耗时？

李城：主要通过场景分级策略：

  • 心智匹配：在复杂在线咨询场景中，用户对模型“深度思考 / 推理”的耗时已有一定容忍度；
  • 策略可配：在 DeskOps 平台中，针对不同业务场景配置检索策略（如最大循环轮数、是否三路并发、优先走 Graph 还是传统 RAG）；
  • 时效优先场景做取舍：对于极端追求毫秒级响应的场景，可降低循环轮次或精简为单路召回，在准确率与速度之间根据业务 ROI 取得平衡。
如果你的企业也在推进类似场景，或正在解决知识检索、流程执行和系统接入等问题，欢迎点击“阅读原文”留下联系方式，与我们进一步交流。