WorkBuddy、Codex把AI竞争推向任务交付，可靠性成为硬门槛

让AI回答“怎么做一份经营分析”，和让它读取销售表、计算指标、生成图表并交出报告，是两个不同层次的产品要求。WorkBuddy和Codex的实践表明，大模型应用开始承担更多实际操作，用户对产品的判断也从回答是否精彩，延伸到任务是否完成。

大模型应用正在进入任务交付的竞争，可靠执行成为落地门槛。一份可验收的成果，需要模型理解目标，也需要最新信息、工具操作、业务规则和结果检查共同参与。模型能力增强，正在重新划分这些环节的职责。

这也解释了微调、RAG、工作流和Agent为何持续交叉：它们分别改善模型能力、任务信息和执行过程。理解路线演变，应先看系统怎样把一次回答组织成一项可以完成、复核和交付的工作。

01 WorkBuddy和Codex让AI直接处理文件并交付成果

WorkBuddy和Codex值得放在一起观察，因为它们把任务执行能力带进了用户真实使用的工作环境。用户交出目标、资料和允许操作的范围，系统读取信息、调用工具并生成文件，成果再回到原来的工作过程。产品承担的职责因此从提供答案，延伸到组织一次实际执行。

腾讯的WorkBuddy产品页把本地文件操作、自主规划和成果交付作为核心能力。更具体的官方实践文档以经营分析为例：用户提供Excel或CSV、指定指标和时间范围，产品读取数据、统计并生成图表或报告。技能文档则说明，可以用脚本和工作流扩展特定任务能力。专业知识、已有程序和模型判断由此进入同一任务过程。

Codex的发展呈现了从代码任务向更广知识工作的延伸。2025年发布时，它已经把读写代码、执行命令和运行测试组织为任务；2026年6月，OpenAI披露的知识工作用途进一步包括报告、表格、演示文稿和研究分析。它在8月的平台文章中又把执行循环开放为可集成的Harness，让其他应用继续拥有自己的业务界面、上下文和工具。

这两个案例提示，专业能力可以由通用模型、任务说明、专业资料、工具和执行控制共同形成。WorkBuddy的“领域专家”或一项Codex任务，也不能仅凭名称认定为一个独立训练的垂类模型。应用专业化正在获得更多实现方式，模型专业化只是其中一种。

02 通用模型增强正在把应用开发重心推向完整任务

通用模型越能理解指令、处理长文档和调用工具，开发者就越少需要为每一种表达方式单独设计处理逻辑。原来必须依靠大量样本训练的部分任务，可以通过指令和示例完成；原来需要手工连接的部分步骤，也可以由模型根据执行结果调整。应用开发因此获得了更大的选择空间。

这一变化有清楚的技术脉络。2018年，GPT早期研究采用预训练后按任务微调的方式；2020年的GPT-3展示了通过上下文中的任务描述和示例完成多类任务的能力。同年，RAG研究把外部检索引入生成过程。到2024年，Berkeley BAIR已用“复合AI系统”概括模型、检索器和外部工具共同完成任务的实践。

几条路线从一开始就存在交叉。RAG并非在微调消失之后出现，工作流也没有等到智能体出现才具备价值。把它们排成一条淘汰链，会掩盖真正的变化：模型承担的通用能力在扩大，应用系统需要补齐的内容随之改变。

03 企业知识需要持续接入，垂类模型只是专业化的一种方式

模型参数适合承载相对稳定、能够跨任务复用的能力；一项任务需要的具体事实，则经常变化。客户刚上传的合同、当天的库存、某个员工可查看的资料，不能都等待下一轮训练后再使用。把这些信息在执行时提供给模型，通常更便于更新，也更便于保留出处和权限。

RAG由此解决了知识接入的一类问题。但企业信息并不只存在于文档里，还包括数据库记录、业务系统状态和工具返回结果。随着任务变长，系统还要持续筛选资料、保留中间结论、清理无关信息。上下文工程的对象因此扩展为模型当前需要的全部信息。Anthropic在2025年的工程文章中，也把信息的选择和维护放到持续执行过程里讨论。

专业训练解决另一类问题：即使资料齐全，模型仍可能反复采用错误的处理方式，或者无法稳定达到专业成果要求。此时，训练可以改善行为、推理和工具使用。选检索还是训练，首先取决于短板来自缺少信息，还是来自不会稳定完成任务；两种短板同时存在时，就需要组合。

04 工作流正在容纳Agent，关键业务规则仍需程序控制

当模型能够自己查资料、选择工具并调整步骤时，逐一规定所有操作的工作流会显得笨重。但企业流程中有两类步骤：一类随情境变化，需要解释和判断；另一类已经有明确规则，需要每次都按规定执行。前者适合增加模型判断，后者仍适合由程序控制。

Dify把Agent放进工作流节点，允许模型在节点内部迭代调用工具；2026年3月又通过Human Input节点，把暂停、人工审核和继续执行变为工作流的原生环节。自主判断和人工参与，由此进入同一套编排。

Salesforce从另一侧说明了相同问题。其Agentforce技术文档将确定性逻辑和模型推理明确分开：条件判断、动作顺序等可以作为代码执行，确实需要理解或判断的位置再调用模型。企业智能体的演进方向，是更准确地划定分工边界；自主程度本身并不是产品能力的充分指标。

05 AI办公的规模化需要稳定执行和可检查的交付结果

把一个模型放进循环，让它不断调用工具，还不足以形成可靠的任务执行产品。任务可能持续数十分钟，经历多次文件修改、工具失败和上下文更新。系统必须知道已经完成什么、下一步依据是什么、发生错误后从哪里恢复，以及最终成果是否符合要求。

OpenAI在Codex平台文章中，把模型周围承担上下文、工具交互、状态和边界管理的执行体系称为Harness。Anthropic针对长时任务的工程实践，则通过初始环境设置、进度文件和版本记录，让后续执行能够接续前面的工作。这些机制共同说明：模型决定下一步的能力，需要执行体系把它转化为连续、可检查的工作。

当产品开始交付文件、代码和业务记录，运行环境也成为产品能力的一部分。文件存放在哪里、执行能否隔离、任务能否恢复、操作结果如何核对，都会影响用户实际拿到的成果。只比较模型回答质量，会漏掉这些差异。

新的组件也要放回各自的位置。工具提供具体操作，MCP提供一种连接工具和资源的协议，Skills组织可复用的说明、脚本和参考资料；执行体系负责在任务中使用它们。组件越来越丰富，但命名本身不能证明任务完成能力。

权威研究正在围绕同一个问题推进：怎样让Agent可靠地使用工具并完成实际操作。Nature的Paper2Agent研究把论文及相关资源组织为可查询的资源层，并在条件允许时构建和验证可执行工具；Science的Biomni研究将专业工具、数据和代码执行纳入科研任务过程。它们关注的是可运行、可验证的系统。

能力提升还需要接受可靠性检验。ICML 2026的一项研究对15个模型开展评估，指出近期能力增益只带来较小的可靠性改善；单个正确率指标无法完整反映重复运行、输入变化和失败后果。因此，一次演示成功不足以代表稳定交付，任务质量、重复执行表现、人工复核和总成本应放在一起观察。

本文来自微信公众号 “亿欧智库”（ID：EOintelligence2017），作者：祝路曼，36氪经授权发布。