李靖怡目前担任金山办公高级算法经理，负责智能体技术在 WPS 的落地。李靖怡认为WPS在探索AI智能体落地过程中真正的挑战并非模型本身的问答能力，而是如何通过坚实的工程架构与精巧的机制设计，将模型潜能转化为稳定、可靠、可交付的系统能力。
WPS没有追求单一的算法范式，而是从办公场景“简单任务与复杂协作并存”的真实痛点出发，创新性地构建了“宽而深”的混合架构——以前端编排器整合信息实现广度覆盖，以分层ReACT机制深耕复杂任务，让智能体在“快速响应”与“深度交付”间取得平衡。
实践充满务实的工程智慧：用任务拆解与结果精炼等轻量化设计替代重型共识算法以保障多智能体协作的收敛性；通过tag-cache与KV-cache的协同，将上下文管理转化为一种基于信息增益的精细化资源投资决策；面对内部海量异构工具，则通过统一的抽象层进行治理，并巧妙利用Code as Action来扩展能力边界。这一切都指向一个核心结论：智能体的进化之路是从“模型能力”迈向“系统能力”，其未来瓶颈将集中于长程状态共享、异步通信与责任边界定义等系统工程与协议层面。WPS的实践表明，驾驭AI智能体的关键在于构建一个能让模型、架构与机制协同进化的“铁三角”系统。
在20216年1月16-17日北京举办的Agentic AI Summit智能体大会上，李靖怡届时将分享智能体在WPS的落地实践，以下是会前采访，剧透一些技术内容。也欢迎你们来Agentic AI Summit大会上听更多的技术话题演讲。
DataFun：WPS选择了 hierarchical reACT + CodeACT + DeepAgents Orchestrator 的混合架构。这种“宽而深”的设计是如何权衡覆盖广度与任务深度的？在办公场景中，这种架构相比单一智能体范式有哪些不可替代的优势？
李靖怡：混合架构构建的初衷是为了支持在办公任务中的各种用户任务需求，有复杂需求也有简单的办公任务。这其实也是办公场景倒逼出来的选择。单一范式很难同时搞定这两类截然不同的需求。我们考虑用编排器整合搜索来源来负责“宽”，统一调度异构信息源，包括邮件、聊天、日程、会议、联网等各路信息来源；用 Hierarchical ReACT 负责“深”，主 Agent 模拟一个追求长期回报最大化的决策体，遇到复杂任务会考虑调动专业子 Agent 独立解决。
架构的核心优势定位于Orchestrator 不再只关注编排，它实际上是在解决一个多动作、多约束的序贯决策问题——它不仅决定合适的触发机制，还决定contextbudget 如何分配。这让我们既能在浅层快速响应，又能在深层稳定交付，而不是在中间搞一种平庸的妥协。
DataFun：在多Agent并行处理复杂任务时，常出现推理链偏移和工具调用冲突。你们在DeepAgents编排器中设计了怎样的冲突消解与协作机制？是否引入了显式的Agent间通信协议或共识算法？
李靖怡：我们没有引入那种很“重”的共识算法，更多还是用工程化的方式让它“能跑通、能收敛、可纠偏”。一方面，复杂任务先把目标拆清楚，明确每一步要产出什么，再按步骤推进；同时我们会有一个比较明确的“完成判定”，避免模型在边界条件上反复兜圈子或者提前收工。另一方面，多Agent并行最怕的是互相污染和互相踩踏，所以我们会把子Agent尽量做成“各自干净地跑一段”，主链路只拿精炼结果。工具层面也会做一些防护。这样即使某一步偏了，也能把它拉回到正确路径上。
DataFun：面对长文档、多工具链的上下文压力，你们提出 tag-cache记忆压缩与KV-cache精准命中。能否详细解释这两种技术是如何协同降低token消耗并保持任务一致性的？在实际部署中，压缩率与任务成功率之间的平衡点如何确定？
李靖怡：Tag-cache 其实是在模拟给大文件打“书签”，也算是一种内存级别的上下文卸载手段，大文件在 WPS办公场景是常见的情况。而 Tag-Cache 的策略把“读不读”变成一种信息投资决策——只有当读取这一段能带来显著的信息增益时，才去花这个成本。KV-cache 则是降低“固定投资”的门槛。二者其实都是为了共同为解决上下文过载问题来协同优化手段的。
DataFun：WPS 365涵盖文档、表格、演示等多工具生态。在推动不同团队的工具接入时，如何保证API语义的一致性？是否设计了自动化工具适配或契约测试框架？
李靖怡：这确实是个脏活。指望几十个团队的接口风格统一是不可能的，公司内部其实针对多个接口的抽象有现成的基建，我们在使用过程中，针对工具的 Agentic 设计中间做了一层“翻译”，不管下面是邮件还是文档，对不同场景、参数维度进行了治理，也适配了一些自动化工具去优化流程。
DataFun：在Excel-Agent等场景中引入CodeACT进行结构化推理，相比纯自然语言驱动的Agent有哪些性能提升？是否遇到代码生成的安全性或执行隔离问题，你们是如何解决的？
李靖怡：在表格场景，CodeACT 的核心还是聚焦 Agent 直接写代码（JS 、Py 或公式）来操作表格，这种“执行即交付”的确定性比纯语言的推理天花板要高不少，同时还能充分利用自定义高阶函数来适配 codeACT 的 skills，充分点亮私域 API 编码的技能树。当然，让模型全局代码把控流程肯定有风险，所以我们也配套了严格的沙盒环境和代码/文件的回滚机制，这样既拿到了代码的高效，又兜住了安全的底。
DataFun：针对SaaS与私有化场景的资源差异，你们提出 fc与prompt双模式自适应。请分享这两种模式在延迟、成本、稳定性上的具体差异，以及业务场景自适应的决策逻辑是如何实现的？
李靖怡：其实算是一种 Agent 落地的工程妥协。SaaS 场景我们优先用 Function Call，因为它原生、快、prefixcache 命中率更可控；但私有化环境里，客户的模型能力参差不齐，我们就切到 Prompt Call 模式，用更精细的提示词工程去“手把手”教模型调工具。系统会自动探测模型能力来做路由，原则就是：能用原生就用原生，原生搞不定就用工程手段兜底，确保用户体验在不同环境下尽量一致。
DataFun：您提到打造“真正的数字员工”需要从“模型能力”迈向“系统能力”。能否阐述一下，在WPS的实践中，当智能体系统从处理单任务升级为支持团队级协作时，整个技术栈的最大瓶颈发生了怎样的转移？
李靖怡：我理解当智能体从“给答案”走向“给结果”，瓶颈就不再是模型能不能做漂亮的问答，而是模型能力外溢后系统或者产品的能力其实滞后了。这时就需要借助模型的肩膀来搭建更加Agentic 化的系统，完成高质量的任务级别的交付。实质上就在模拟能不能像一个真正的同事一样，把一件事从头到尾做完、做对、做得让团队放心用。技术栈的最大转移还是前面搭建的这套混合分层的异构 Agent 引擎，借助针对性的工具治理和上下文工程手段优化，来逐步完成能力的跃升。
DataFun：在群聊协作等动态场景中，你们提到子Agent裁剪与排序策略。这是基于任务类型、历史表现还是实时负载进行决策？是否有引入强化学习进行动态调度优化？
李靖怡：还是关于 contextoffload 的策略问题， subAgent 也好，fileSystem 也好，包括前面介绍的 Tag-BasedCache，本质都是为主流程 context 减负的手段， subAgent 的裁剪在我们办公场景是一个有效策略，但也并不全能，确实需要参考不同任务类型来适配不同的策略，很难达成所谓“赢者通吃”。RL 策略我们在对话模型和多轮工具调用进行了探索落地，不过对于上下文层面的动态调控，在无法明确量化 TokenROI 或者预期回答的质量奖励的情况下，还是以上下文工程手段介入为主。
DataFun：在WPS 365的办公场景中，智能体需调度邮件、日程、会议、文档等功能与协议各异的工具。为实现高效、安全的调度，你们如何设计统一的工具抽象层（例如基于MCP协议）来“治理”这些异构工具？关键挑战是什么，又如何确保抽象层既能覆盖工具共性、又能暴露必要的业务特性？
李靖怡：本质还是企业内部 API 抽象和 Agentic场景的适配建设问题，我们围绕现有的WPS365 的 API 基建进行了一定程度的工具治理，原子化后兼容工具调用和 MCP 协议，关键挑战还是对于企业内部 API<