ARTICLE · 1211928
AI Agent进入系统工程阶段
★Runtime、Harness与Context如何重塑Agent产品易一 · 行业研究2026年10月
Agent已经执行任务很久了。代码Agent可以读取代码库、调用Shell、修改文件并运行测试；浏览器Agent也早已能够点击页面、填写表单和完成简单流程。
2026年的变化更多发生在工程层：模型侧的Computer Use、长链路推理和连续Tool Use继续增强，运行侧逐步形成围绕状态、沙箱、连接器、权限、重试、Tracing和评测的一整套基础设施。
从产品形态看，办公Agent与个人Agent正在沿两条路径推进。WorkBuddy代表生产力与企业场景：模型、MCP、Skills、办公Context和企业部署被放进同一平台；Muse代表个人事务场景：每位用户拥有独立云端环境，Agent可以在后台持续运行，并通过独立审批模块处理凭证、支付与高风险操作。
本文重点讨论六个问题：
Agent系统为什么越来越像一套完整的软件基础设施 Runtime与Harness分别承担什么角色 Context如何从“上下文窗口”演变为任务上下文 MCP、Skills与Connector如何连接外部工具 Personal Agent与Enterprise Agent为何开始走向不同工程路径 可靠性、权限与成本如何成为后续产品迭代的长期约束
01｜Agent的产品边界继续外延
从Chatbot到Agent，变化可以沿“责任边界”来观察。
Chatbot主要输出内容；Copilot嵌入既有软件并辅助某一步骤；代码Agent已经可以在IDE、Terminal和代码库中自主执行较长链路任务；办公Agent进一步处理文档、表格、邮件、会议、浏览器和业务系统，并把结果交付为可直接使用的文件或业务记录。
这一区分对工程架构有直接影响。内容生成可以把大部分不确定性交给用户判断；任务执行则必须处理状态、工具选择、异常恢复、权限、验证和回滚。
任务越长，失败方式越多，单次模型调用在整个系统中的占比越低。
★AI Agent技术栈全景图
02｜为什么近期工程化速度明显加快
近期Agent产品的推进来自模型能力与工程基础设施同时演进。
模型端，Computer Use、连续Tool Use、多步推理、长上下文和专业文档生成降低了任务拆解与工具调用的难度；工程端，Agent Loop、Sandbox、持久化状态、MCP / Skills / Connector以及企业治理逐步形成可复用组件。
可以把这组变化拆成六类：
Computer Use模型可以直接理解并操作图形界面，覆盖缺少标准API的遗留软件与网页。
连续Tool Use任务从“一次调用一个工具”变为多轮规划、执行、观察与修正。
长上下文与Compaction允许Agent处理更多文件和更长任务，同时通过压缩维持有效上下文。
Sandbox把Shell、文件系统、浏览器等执行能力放进隔离环境，降低真实任务执行的安全风险。
MCP / Skills / Connector工具接入逐步标准化，减少每个应用单独开发适配层的成本。
Tracing / Evals任务轨迹被记录、复现和回归测试，Agent开始具备持续工程优化的基础。
这里的变化并不是“Agent第一次能做事”，而是Agent逐步具备生产环境需要的稳定性、可观察性与治理能力。
03｜Runtime与Harness：Agent的执行层
一个可持续运行的Agent系统通常包含两层概念。
Runtime负责把Agent“跑起来”：提供执行环境、状态、会话、工具访问、凭证、资源限制和任务调度。
Harness负责把概率性的模型放进可控流程：什么时候规划、调用什么工具、如何拼接Context、怎样验证输出、失败后是否重试、何时请求人工确认。
不同框架对这两层的抽象并不一致。主流框架通常都会涉及Agent Loop、State、Session、Tool Calling、Tracing、Checkpoint、Interrupt、Memory和Evals，只是控制粒度和默认抽象不同。
同一基础模型放入不同Harness后，任务完成率、延迟、Token消耗和人工介入次数都可能变化。因此，模型升级并不意味着产品升级可以自动完成；上下文排序、缓存策略、Tool Schema、失败处理和评测集都需要同步调整。
Harness优化通常发生在哪些层
04｜Context Engineering：从上下文窗口到任务上下文
长上下文扩大了模型一次可读取的信息量，但Agent面对的问题并不只是“能装多少Token”。
长期任务要求系统持续决定哪些信息进入当前上下文、哪些应压缩、哪些可以从外部存储重新检索。
一个成熟Agent的Context通常至少包含五层：
即时上下文当前任务目标、用户指令、最近工具结果与错误信息。
业务上下文文档、邮件、会议、CRM / ERP记录、项目状态和组织权限。
长期记忆用户偏好、历史决策、常用流程、个人或团队习惯。
运行状态已完成步骤、未完成子任务、检查点、失败位置和重试记录。
安全上下文身份、角色、授权范围、敏感数据边界和审批条件。
WorkBuddy的产品路径说明了企业Context的重要性。企业微信、腾讯文档、腾讯会议、知识库等过程数据带有协作关系和业务语义，适合被Agent作为运行时Context使用。
进入企业部署后，Context同时受到权限、合规和数据授权约束。“可以读取”与“可以用于训练”需要分开处理。
05｜MCP、Skills与Connector：工具接入进入标准化阶段
Agent的执行范围受外部系统开放程度约束。
API适合结构化、稳定且有明确权限边界的业务；Browser / Computer Use覆盖更广，但容易受到页面变化、验证码、反自动化策略和登录流程影响。
MCP、Skills与Connector位于两者之间，把工具、数据源和任务模板以更统一的方式暴露给Agent。
可以简单区分：
Connector解决“连接到哪里”，通常处理身份、授权、数据源与应用接入。
MCP解决“如何把工具与资源暴露给模型 / Agent”，提供较统一的工具调用协议。
Skills解决“如何把任务方法封装起来”，更接近可复用的工作流、领域步骤和失败处理经验。
WorkBuddy通过连接器接入文档、邮箱、会议、知识库等产品，并把高频办公流程封装为Skills。这样的设计降低了用户直接面对模型、API和复杂配置的门槛，也使平台可以在工具层持续扩展。
★Agent执行路径对比
06｜WorkBuddy：生产力Agent的工程路径
WorkBuddy的产品路径带有明显的代码Agent技术继承。
其早期底座来自CodeBuddy，随后把界面、Skills与办公场景重新组织，将编程Agent已有的任务循环、MCP、Sandbox和模型适配能力迁移到非技术用户。
可以把它的工程路径概括为：
多模型：内置多家模型并允许自定义API，平台可按任务路由模型。 工作模式分层：Ask、Plan、Craft对应问答、先规划后执行和直接执行。 移动入口：通过微信等入口远程触发桌面端任务，Agent在后台执行后返回结果。 办公Context：文档、邮箱、会议、知识库、项目管理等产品可在同一账户与权限体系下被调用。 SkillHub：把标准任务流程沉淀为技能，提高非技术用户的可用性。 企业版：将专家Agent、云端持续运行、团队协作和管理后台纳入部署体系。
多模型策略也体现了Agent产品与单模型产品的差异。复杂任务的上限仍受模型影响，但平台可以通过路由和自定义模型接入降低单一模型波动对产品体验的影响。
与此同时，自研模型与Runtime / Harness之间可以进行协同优化，用执行轨迹改进工具调用、上下文使用和成本结构。
★WorkBuddy工程路径
07｜Muse：Personal Agent的云端Runtime
Muse采用了另一套更偏个人事务的架构。
每位用户拥有独立云端Linux虚拟机，浏览器、文件系统和终端在云端持续运行；手机、网页与WhatsApp主要承担任务下达、进度查看和审批。Mac端在授权后可以读取本地文件、邮件和日历，但推理与主要执行仍在云端完成。
审批与执行分离
Muse的虚拟机内部把工作区与安全区分开。
工作区处理网页、文件等不可信内容；安全区保存凭证库和审批模块Sentinel。外部操作需要Sentinel批准，需要用户确认的高风险动作由审批模块直接推送到客户端。
凭证通过代理Token提供给Agent，支付环节使用锁定商户和金额、短时有效的一次性虚拟卡，减少真实卡号暴露。
长期记忆
Muse把对话、交互偏好、授权邮箱 / 日历和用户上传文档写入长期记忆，并在运行时按语义检索。
这种设计使Personal Agent可以把多场景历史放在同一用户Context下，也带来新的隐私、数据边界和迁移问题。
★Muse云端Runtime架构
08｜Browser / Computer Use的覆盖面与限制
通用Browser Agent的吸引力来自覆盖面：只要人可以在网页上操作，Agent理论上也可以尝试执行。
但浏览器不是稳定API。页面结构、风控、验证码、登录状态、会员权益、支付验证和App跳转都可能让流程中断。
公开实测显示，酒店类OTA的结果获取率已经较高，但航司官网未取得结果的比例仍明显更高，常见原因包括人机验证、访问拒绝、IP封禁和需要跳转App。部分场景即使人工接管后仍无法继续。
这说明Browser / Computer Use更适合覆盖长尾软件和缺少结构化接口的场景；当官方API或Connector可用时，平台通常会优先采用更稳定的结构化接口。
API-first与Browser-first的差异
09｜Reliability：长任务如何被验证
办公与个人事务缺少代码编译器这类天然验证器。
Agent完成一份报告、一张表格、一封邮件或一次预订后，系统仍需要判断内容是否完整、数据是否一致、操作是否符合用户意图。
常见方法包括：
规则验证：字段完整性、格式、数值范围、引用与数据一致性。 工具验证：重新查询外部系统，确认记录是否已经写入或交易是否成功。 模型复核：使用第二次推理或独立Reviewer检查任务结果。 Checkpoint：长任务阶段性保存状态，失败后从检查点恢复。 Retry Policy：区分可重试错误、需要切换工具 / 模型的错误和必须人工介入的错误。 Human-in-the-loop：支付、发送外部邮件、删除数据、变更权限等动作设置审批。 Evals：使用真实任务集持续跑回归测试，监控成功率、延迟、Token成本和人工介入。
公开测试中仍可以看到税前 / 含税价格混用、票价档次与行李政策混淆、往返任务首轮只返回去程等问题。
这些案例说明，“流程跑通”与“结果可靠”需要分别评估。
★Agent可靠性闭环
10｜Enterprise Agent：治理层开始成为产品的一部分
企业部署会把Agent从个人工具变成受管理的软件主体。
它需要身份、权限、数据边界、审计、版本管理和成本控制，并与企业现有安全体系连接。
常见治理能力包括：
Identity / RBACAgent以什么身份访问文件、邮箱、CRM和内部系统。
Secrets ManagementAPI Key、数据库凭证和支付凭证如何托管与最小化暴露。
Audit / Trace谁在什么时间触发了什么任务，Agent调用了哪些工具并修改了哪些数据。
Approval Policy哪些动作自动执行，哪些需要用户、主管或合规人员批准。
Data Boundary不同部门、项目、地区和租户之间的数据隔离。
Version / RollbackPrompt、Workflow、Skill、模型版本变化后如何回滚。
Budget / Quota长任务、模型路由和并行Sub-agent可能快速增加推理与计算成本。
Evals / SLA企业采购会逐步要求可度量的成功率、稳定性、延迟和恢复能力。
11｜Personal Agent与Enterprise Agent开始出现不同的工程重点
两条路线会共享模型、工具协议和部分Runtime组件，但对权限、记忆、支付、数据边界和可靠性的要求不同。
随着Agent承担的任务变长，产品设计可能进一步分层：个人Agent更关注跨场景连续性与用户授权，企业Agent更关注可控、可审计和可复现。
12｜行业观察
从目前产品进展看，可以观察到几条相对清晰的方向：
Agent工程正在从应用内部逻辑演变为独立基础设施。 Runtime、State、Sandbox、Tracing、Evals等能力逐步平台化。 Harness仍会保持较强的产品相关性。 模型相同，Context组织、工具设计、验证与重试策略不同，最终体验仍可能存在明显差异。 Context的讨论正在从“上下文窗口长度”转向“任务所需信息能否被正确获取、压缩、授权和持续更新”。 工具生态将长期混合存在。 API、Connector和MCP负责稳定主路径，Browser / Computer Use覆盖缺少结构化接口的长尾软件。 Personal Agent与Enterprise Agent可能共享底层协议，但在身份、审批、Memory、数据边界和成本模型上逐步分化。 长任务可靠性仍是产品迭代的重要约束。 结果验证、异常恢复、审批边界和Evals会持续占用大量工程资源。
参考来源
券商行业研究资料、公司官网与开发者文档、公开行业资料、行业媒体与数据库，易一整理。
