WorkBuddy的架构启示：企业级Agent的“手”应该长什么样？

一、断层：模型说“我要做”，谁来保证“真做了”

讲AI Agent的文章常说：大模型是“大脑”，工具调用是“手”。但真正在企业里落地过Agent的人知道，大脑和手之间有一条鸿沟。

模型输出的工具调用，只是一项行动意图。它没自动获得用户身份，不代表企业策略允许执行，也不能证明远程系统真的产生了预期结果。

看一段最朴素的Agent循环：

def naive_agent_loop(task, tools):
    messages = [{"role": "user", "content": task}]
    for _ in range(max_steps):
        resp = llm.chat(messages, tools=tools)
        if resp.tool_calls:
            for tc in resp.tool_calls:
                result = execute_tool(tc)  # 没有权限检查
                messages.append({"role": "tool", "content": result})
        else:
            return resp.content

能跑，但上不了线。没有权限边界，上下文全量传给模型，中断无法恢复。

WorkBuddy团队的复盘说得直白：模型只承担其中一部分，工具接入、上下文组织、权限边界、结果验证、反馈纠正、跨会话延续，都直接影响产品是否可靠。

这不是一家的问题。行业里有个更准确的名字：认知-执行断层。大模型懂语义、会推理，却落不到企业异构系统的操作层；传统RPA能跨系统操作，却看不懂业务语义，适应不了动态界面和无API系统。两边割裂。

所以企业级Agent的“手”不能只是“能调用工具”，必须回答四个问题：谁在调用、以什么身份调用、允许调用什么、调用之后怎么验证。

本文以WorkBuddy和实在Agent为双样本。前者偏桌面端轻量执行，后者偏企业级跨系统重型自动化，路线不同，但在执行层的核心命题上给出了高度一致的答案。

二、一只“受控的手”的五个维度

WorkBuddy的系统分五层：基础设施、智能体底座、能力服务、业务应用、用户交互，每层只与相邻层通信。与“手”最相关的是智能体底座层（工具调用与执行监控）和能力服务层（Skill、MCP等外部能力接入）。

在这个架构下，执行层有五个约束维度。实在Agent的“思考-行动”双循环，为每个维度提供了企业级的纵深注脚。

2.1 权限边界：先划定范围，再放手

传统Agent权限多是“全有或全无”，企业场景要求更细。WorkBuddy的Harness层用三级枚举：

class PermissionMode(Enum):
    READ_ONLY = "read_only"       # 只读，禁止写入
    WORKSPACE_WRITE = "workspace" # 仅工作空间可写
    FULL_ACCESS = "full"          # 无限制

每次工具调用前，Harness检查当前会话权限是否允许。问题不是“能不能动”，而是“在什么范围内能动”。

实在Agent把权限拆成四层隔离：身份隔离（Agent账号与员工账号、其他Agent账号互不串用）、操作隔离（能操作哪些窗口、控件、路径）、数据隔离（能读哪些字段、写哪些表）、环境隔离（开发与生产严格分离）。核心就一句：权限粒度不该停在“角色级”，要下探到“操作对象级”。

启示：权限应是声明式的——工具和Skill注册时声明所需级别，Harness运行时强制执行。不是事后审计，而是执行前拦截。从WorkBuddy的三级枚举到实在Agent的四维隔离，逻辑一致：先划定范围，再放手。

2.2 身份与凭证：每只手都得有“实名”

一个容易被忽略的问题：Agent执行操作时，到底以谁的身份在执行？

员工让Agent“查一下本季度销售数据”，Agent不该用自己的超级权限去查，而应以该员工的身份和权限去查。员工看不到的数据，Agent也不能帮他看。

WorkBuddy Enterprise把企业权限体系（OneID统一登录）与执行链路绑定。Azure SRE Agent的做法是用隔离的身份sidecar管理令牌，令牌范围限定于单次调用。

实在Agent做了一道更底层的切割：Agent账号与企业员工权限体系解耦，避免“一人通吃”。即使Agent因业务需要获得较高系统权限，也不会继承任何员工身份去越权。微软Entra Agent ID同样主张给Agent分配专用唯一身份，并明确所有者、发起人和审批人。

启示：每次工具调用都应有明确的执行身份，来源是当前用户授权，而非Agent的系统身份。权限决定“能做什么”，身份决定“替谁做”——这是企业级产品与Demo级Agent的分水岭。

2.3 工具注册与渐进式披露：不是所有工具都该被模型看见

上下文预算常被低估。注册100个工具，每个描述50个token，系统提示词就多出5000个token，还不算参数Schema。工具越多，模型选得越不准。

WorkBuddy用Skill机制做渐进式披露：初始只加载少量核心工具，任务需要时再动态加载对应Skill及其工具。10项技能大约只产生1000个token开销。每个Skill还是一个自包含的mini-Agent，封装领域知识、操作步骤和工作规范，内部子路由决定具体调哪个工具。

实在Agent从另一个方向解题：不让模型自由“选”工具，而是用TARS大模型的六层拆解引擎——目标理解、规则抽取、任务树生成、工具编排、执行校验、记忆沉淀——把工具调用变成结构化编排。用户输入“收集京东销量前20的手机信息，生成Excel存桌面，钉钉发给老板”，系统自动拆成数据获取、数据处理、结果交付三段，每段匹配对应工具，规划过程可视化，确认后一键执行。工具选择的准确率，从模型层转移到了工程层。

启示：工具管理不该是平坦列表，而应有层级——顶层意图路由，中层Skill调度或任务树编排，底层具体执行。可见性按需扩展。WorkBuddy用Skill渐进披露，实在Agent用规划引擎结构化编排，都在回答同一个问题：如何不让模型在工具海洋里迷失。

2.4 执行沙箱：物理隔离比协议约束更可靠

企业Agent常要执行代码、操作文件、访问数据库，直接在宿主机上跑，风险不可控。

WorkBuddy支持云端沙箱与本地执行双模式：云端部署在腾讯云，负责任务执行与模型调度；本地在用户电脑上创建独立环境，含Python解释器、第三方库和浏览器驱动。用户按任务敏感度选择。

实在Agent走得更激进：不通过API调用，而是用ISSUT（智能屏幕语义理解）让Agent像人一样“看”懂屏幕，在沙箱中转化为结构化GUI事件。这意味着操作路径被限制在“人能看到、人能做到”的范围内——绕不过界面直接操作数据库，也执行不了Shell命令。这是物理级权限围栏，比协议层约束更难绕过。

ISSUT的路径是“视觉编码+语义映射”：轻量CV模型实时捕获屏幕，检测可交互元素，生成视觉与空间特征向量，再与预训练业务语义空间对齐。所以它的执行能力不依赖目标系统是否开放API，而依赖能否“看懂”界面——这恰恰是大量老旧系统和信创环境的现实需求。

启示：沙箱不该是可选，而是默认。按风险分层：只读查询可轻沙箱，写操作和代码执行必须强隔离。实在Agent的实践更进一步：隔离方式本身可以成为权限边界——操作方式被限制在“屏幕操作”层面时，系统级命令天然就执行不了。

2.5 结果验证与可观测性：做完之后怎么知道“做对了”

API返回200，不代表任务完成。模型说“已发送给客户”，不代表邮件真到了。

传统Agent靠模型自判，但模型对“成功”往往过于乐观。WorkBuddy的Harness在每步执行后检查产出是否符合预期，这是产品侧的程序化验证，不依赖模型自评。

实在Agent的双循环提供更细的反馈：TARS输出步骤序列，ISSUT映射为界面操作，结果回传TARS判断是否与预期一致，不一致则重试或切换策略。ERP显示库存不足，Agent不会机械报错，而是按预设策略触发紧急采购并调整后续审批节点。每次判断都记录触发条件、推理路径、调用规则和最终结论，合规人员可直接复核——这解决了审计最头疼的问题：出了问题，能不能知道是哪个环节、哪一步、由谁触发的。

启示：企业级Agent要区分“模型认为成功了”和“系统验证成功了”。验证应是确定性的，基于系统状态而非模型推断。每次调用都留结构化审计记录：身份、环境、时间、结果。实在Agent的“可解释决策输出”值得借鉴——不只记“做了什么”，还记“为什么”。

三、五条通用设计原则

原则一：意图与执行分离。 模型只输出行动意图，Harness负责校验参数、检查权限、绑定身份、执行工具、验证结果。目的是让执行可审计、可回滚、可治理。实在Agent的“双循环”是极致体现：TARS思考规划，ISSUT+RPA精准执行，通过结果反馈闭环。

原则二：默认最小权限。 启动时处于最小权限，需要时显式授权扩展。比“先给全部权限再限制”更可靠，攻击面更小。权限模型的精细度，决定Agent能在多高风险的环境里运行。

原则三：工具能力可组合但不可扁平。 用Skill封装领域工具组，用渐进披露或结构化编排控制上下文。这既是效率问题，也是准确率问题。

原则四：执行环境默认隔离。 工具调用不该发生在推理进程内，而应在隔离沙箱或容器中。粒度可按风险动态调整。实在Agent提供了另一种思路：不是限制“能做什么”，而是限制“怎么做”来实现天然边界。

原则五：验证优先于信任。 不依赖模型自判，用程序化逻辑检查每步产出。不可逆操作前加人工确认。实在Agent进一步要求：验证不仅要知道“对不对”，还要知道“为什么”。

四、一只“好手”的标准

如果只用一句话回答：企业环境里可用的手，不是能调用最多工具的手，而是每一次调用都可追溯、可审计、可回滚的手。

WorkBuddy的实践揭示了一个判断：Agent Loop只是最基础的一层，真正让Agent稳定运行的，是Loop外面的上下文隔离、权限控制和结果验证。实在Agent补充了另一个维度：在认知与执行存在结构性断层时，“手”的设计不能只想“怎么抓”，还要想“抓什么”和“谁允许抓”。

实在Agent以90.2%的任务成功率登顶OSWorld全球总榜，首个突破90%大关的Computer-Use Agent。这个数据侧面验证了一个判断：执行层的工程成熟度，而非模型本身的推理能力，正在成为企业级Agent性能的分水岭。

对正在构建企业级Agent的团队意味着什么？工具调用代码可能只占执行层工作量的20%，剩下80%在权限系统、审计日志、沙箱管理和结果验证上。如果还把“能调用工具”当作Agent完成的标志，距离生产可用还有很长的路。

企业级Agent的竞争，最终不是模型能力的竞争，而是执行层工程成熟度的竞争。WorkBuddy用Harness约束Loop、用身份绑定调用、用沙箱隔离执行、用验证替代信任；实在Agent用TARS规划任务、用ISSUT理解界面、用RPA执行操作、用双循环闭环验证——这是这个方向上值得参考的两个样本。