1. 背景与问题
企业 Agent 正从"网页对话、生成建议"走向"进入业务与工作环境、执行任务、验证结果"。
以 Codex、Claude 等本地 Agent 工具为代表的能力形态,已具备较强的 Harness 能力:它们可以理解本地项目和文件上下文,调用终端、Git、IDE、浏览器、脚本与测试工具,并根据真实反馈持续修正行动。对于研发、IT 运维、文件处理、数据分析和桌面自动化等场景,这类体验通常优于纯网页端 Agent。
与此同时,企业核心业务中存在大量流程确定、上下游关联复杂的场景:
订单 → 审核 → 库存 → 发货 → 售后 → 财务对账
线索 → 分配 → 跟进 → 报价 → 合同 → 回款
告警 → 归因 → 工单 → 处理 → 验收 → 复盘
这类流程需要跨部门协同、统一业务状态、权限、审计、重试、补偿和 SLA,不应散落在个人电脑上的本地 Agent 中。
1.1 纯云端 B/S Agent 的不足
- 难以原生进入本地文件、代码仓库、IDE、终端、桌面应用和隔离内网;
- 常停留在"给方案",用户仍需手工执行、测试与回填结果;
- 对调试、试错、验证和遗留系统操作等动态任务的闭环能力不足;
- 为访问内网或本地资源而直接扩大云端权限,会增加安全风险。
1.2 纯本地 C/S Agent 的不足
- Skill、工具配置、上下文和执行经验分散,难以沉淀为组织资产;
- 难统一管理模型、权限、审批、审计、成本和版本;
- 不适合承担跨部门、高并发、确定性的业务流程;
- 终端工具权限很高,缺乏边界时可能成为数据泄露和误操作入口。
1.3 核心矛盾
业务需要 Agent 深入真实环境完成任务
VS
企业需要统一治理数据、权限、流程与责任
2. 架构决策
2.1 决策结论
| 任务特征 | 执行方式 |
|---|---|
| 上下游明确、规则稳定、系统可安全云端接入 | 云端业务工作流 + 受限 AI 决策节点 |
| 依赖本地/内网环境,路径无法预定义,需要工具调用和验证 | 本地 Harness Agent |
| 主流程在云端,但局部需本地或内网动作 | 云端编排 + 本地受控执行 |
复杂度不是路由条件。 更重要的是流程确定性、资源位置、数据等级、动作风险和对真实环境验证的依赖。
2.2 为什么采用混合架构
| 方案 | 优势 | 关键短板 | 结论 |
|---|---|---|---|
| 纯 B/S 云端 Agent | 易部署、易扩容、易协作、易治理 | 难完成本地和内网的深度执行闭环 | 不单独采用 |
| 纯 C/S 本地 Agent | Harness 强、上下文丰富、执行与验证强 | 能力孤岛、治理与规模化不足 | 不单独采用 |
| 云端 + 本地混合架构 | 同时覆盖业务流程治理与现场执行 | 需处理跨端身份、数据和状态复杂度 | 推荐采用 |
混合架构不是让所有任务跨端执行:
- 能在云端闭环的确定性流程,保持云端执行。
- 仅涉及个人本地生产力的低风险任务,可在本地闭环,仅回传必要结果。
- 确有跨端依赖的高价值任务,才采用云端编排 + 本地执行。
2.3 设计原则
- 流程确定优先于 Agent 自主性:能用状态机和 Workflow 实现的主路径,不交给模型自由规划。
- 策略优先于模型判断:模型可以建议动作,但策略、审批和执行器决定是否执行。
- 云端全局控制,本地最小执行:云端统一身份、策略、状态与审计;本地只获得完成任务所需的最小权限。
- 数据最小化流动:本地优先检索、脱敏、摘要,仅将模型推理所需的上下文发送至云端。
- 关键操作可恢复:关键写操作必须具备幂等、检查点、补偿、审计和人工接管能力。
- 本地 Agent 不等于本地模型:模型仍可通过云端模型网关统一治理;"本地"主要指工具、数据和执行环境所在位置。
3. 总体架构

3.1 云端控制面
| 模块 | 职责 |
|---|---|
| Web 工作台 | 对话、任务发起、任务进度、结果查看和审批 |
| 身份与权限 | 租户、用户、角色、设备与 Agent 身份治理 |
| 任务路由 | 根据流程、资源、数据和风险决定执行面 |
| 业务工作流运行时 | 运行确定性业务链路,管理状态、重试、补偿和异常 |
| 模型网关 | 模型路由、脱敏、限流、成本归因与供应商治理 |
| 知识与 Skill 中心 | 共享知识、Skill 注册、版本、权限和评估 |
| 策略与审计 | 风险分级、审批、日志、Trace、评估和追责 |
3.2 本地/内网执行面
| 模块 | 职责 |
|---|---|
| 本地 Agent 执行器 | 设备身份、任务领取、任务校验、结果回传 |
| 本地 Harness Runtime | 观察环境、调用工具、读取反馈、迭代执行和验证 |
| 工具适配器 | 文件、终端、IDE、Git、浏览器、桌面工具与内网系统 |
| Sandbox | 目录、进程、网络、时间和资源隔离 |
| 本地策略校验 | 校验任务签名、工具白名单、数据范围和审批令牌 |
4. 执行模式与边界
4.1 云端业务工作流:确定性业务的统一中枢
适用条件:
-
主流程、状态转换和责任边界可定义;
-
上下游系统可通过 API、消息总线或专用连接器接入;
-
需要统一业务状态、跨部门协作、高并发与审计。
业务事件触发
→ Workflow / 状态机编排
→ 调用上下游系统
→ AI 节点进行分类、摘要、归因或建议
→ 规则校验与审批
→ 状态回写、异常升级、流程结束
典型场景:客服工单分流与质检、订单审核、库存异常处理、销售线索流转、经营异常派单、财务对账和合规检查。
实施约束:
- 主流程由 Workflow/状态机控制,而非自主 Agent;
- AI 节点必须使用结构化输入输出,并在进入下游系统前通过业务规则校验;
- 所有业务写操作使用幂等键,避免重复扣款、重复派单或重复写入;
- 对跨系统失败采用补偿事务(Saga),而非假设分布式事务一定成功;
- 超时、重试失败的事件进入死信队列,并可转人工接管。
4.1.1 业务事实来源与状态责任矩阵(P0)
对订单、库存、合同、工单、客户等业务对象,Agent 和 Workflow 不能成为事实来源系统。下表是治理模板,并非已确认的企业系统映射;每个场景必须在"场景准入卡"中填写真实系统、接口 Owner 和事件契约后,方可进入实施。
| 业务对象 | 事实来源系统 | Workflow 可执行动作 | 状态变更责任方 | 事件来源 | 幂等标识 | 失败补偿/人工 Owner |
|---|---|---|---|---|---|---|
| 订单 | 订单事实来源系统(准入卡填写) | 查询、校验、发起受控操作 | 订单事实来源系统 | 订单状态事件 | 订单号 + 操作类型 | 订单运营负责人 |
| 库存 | 库存事实来源系统(准入卡填写) | 查询、预占申请、异常派单 | 库存事实来源系统 | 库存状态事件 | 库存单号 + 版本 | 供应链负责人 |
| 合同 | 合同事实来源系统(准入卡填写) | 信息抽取、审批发起、归档 | 合同事实来源系统 | 合同状态事件 | 合同号 + 版本 | 法务/财务负责人 |
| 工单 | 工单事实来源系统(准入卡填写) | 分类、派发、催办、升级 | 工单事实来源系统 | 工单状态事件 | 工单号 + 动作 | 工单业务 Owner |
实施要求:
- Workflow 的任务库只保存编排状态、审计记录和关联标识,不替代业务主数据;
- 所有跨系统调用携带业务关联 ID、幂等键和可追溯的操作者身份;
- 下游未确认成功前不得将上游业务状态标记为完成;
- 发生状态冲突、无法补偿或超过重试阈值时,冻结自动推进并转业务 Owner 人工裁决;
- 各业务域上线前须完成事实来源、事件契约、回滚/补偿和人工兜底责任确认。
4.2 本地 Harness Agent:真实工作环境的受控执行器
适用条件:
-
需要操作本地文件、代码库、IDE、终端、浏览器或桌面软件;
-
需要访问不宜暴露至云端的内网资源;
-
任务路径依赖运行时反馈,需要调试、试错、修复与验证。
任务领取
→ 观察本地环境
→ 调用受限工具
→ 获取日志、测试、文件或页面反馈
→ 调整行动
→ 验证结果
→ 回传结构化结果与证据
典型场景:代码修复与测试、本地文档/Excel 处理、浏览器和桌面软件操作、内网日志分析、IT 故障排查。
4.3 云端编排 + 本地执行:跨端任务闭环
云端 Workflow 创建任务
→ 本地执行器领取经授权的任务包
→ 本地 Harness 获取证据、执行和验证
→ 回传结构化结果、产物引用与 Trace
→ 云端继续审批、工单流转、通知和复盘
例如:云端经营系统发现异常 → 创建诊断任务 → 本地 Agent 读取内网日志并运行检查 → 回传证据 → 云端派发工单并跟踪闭环。
5. 任务路由机制
路由逻辑由确定规则驱动,模型仅可在低风险、非关键场景中辅助分类。
0. 数据是否允许在目标执行面、模型、日志和 Trace 中处理?
否 → 调整数据范围、切换专用环境或拒绝任务
1. 是否包含高风险写操作?
是 → 先绑定审批、双确认、回滚和人工接管;未满足则不路由
2. 主流程是否可预定义?
是 → 必须由云端 Workflow / 状态机持有业务编排状态
否 → 按资源位置选择云端或本地 Agent Runtime
3. 所需系统和数据能否全部由云端安全访问?
是 → 云端执行
否 → 继续判断本地/内网执行需求
4. 是否依赖本地工具、内网资源或真实环境验证?
是,且第 2 步为"流程可预定义" → 云端编排 + 本地执行
是,且第 2 步为"流程不可预定义" → 本地 Harness / 内网执行器
5. 不依赖本地资源且流程不可预定义?
是 → 云端 Agent Runtime
强制规则:确定性业务流程即使局部动作在本地完成,业务状态中枢仍保留在云端 Workflow;本地 Harness 只执行受控的局部 Skill,不得替代业务事实来源或流程中枢。
| 任务类型 | 首选执行面 |
|---|---|
| 客服工单、订单、库存、经营异常等确定业务链 | 云端业务工作流 |
| 云上 SaaS/API、批量报表、企业知识问答 | 云端执行 |
| 编码、测试、本地文件、桌面操作 | 本地 Harness |
| 内网日志、遗留系统、设备环境 | 本地/内网执行器 |
| 云端告警后采集本地证据并处理 | 云端编排 + 本地执行 |
6. 劣势、风险与处理策略
| 维度 | 云端业务工作流的劣势 | 本地 Harness 的劣势 | 处理策略 |
|---|---|---|---|
| 真实环境 | 不擅长本地工具、桌面与隔离内网 | 仅覆盖单设备或局部网络 | 云端编排、本地受控执行 |
| 业务协同 | 遗留系统接入成本较高 | 不宜承担跨部门业务中枢 | 云端统一持有业务状态与责任链 |
| 流程变化 | 跨系统改动的测试与发布周期较长 | 个人配置与工具版本易分叉 | 云端管理 Skill、版本与灰度 |
| 数据风险 | 可能产生数据上云、日志留存风险 | 终端丢失、恶意软件、误操作风险更高 | 数据分级、最小化传输、终端安全基线 |
| 安全攻击面 | 集中 API 与凭证受攻击时影响面大 | 工具权限强,可能被恶意内容诱导 | 云端策略 + 本地 Sandbox、白名单、审批 |
| 可用性 | 依赖云服务、网络与模型供应商 | 依赖设备在线、客户端版本与本地资源 | 云端重试/补偿;本地租约与断点恢复 |
| 成本 | 模型、云资源、集成和可观测成本累积 | 客户端、兼容性和终端支持成本高 | 仅为高价值任务部署本地 Runner |
| 审计复现 | 易记录流程,但难感知本地细节 | 环境差异使问题难复现 | 回传版本、Trace、验证结果与证据 |
6.1 明确禁止的反模式
云端不得:
- 向终端下发任意 Shell 命令或任意脚本;
- 在缺少幂等、补偿与审批时执行关键业务写操作;
- 将固定业务主流程改为不可预测的自主 Agent;
- 未完成数据分级即处理核心敏感数据。
本地不得:
- 成为订单、合同、库存、工单等业务的唯一状态来源;
- 保存用户密码、长期 Token 或企业核心密钥;
- 以个人 Prompt、脚本或权限绕过企业治理;
- 在无审批、无审计、无回滚条件下执行高风险动作。
7. 本地执行器安全契约
云端下发的是经签名、受限、可审计的任务包,而不是任意命令:
{
"task_id": "唯一任务编号",
"actor": "用户、角色与租户",
"required_capabilities": ["git.read", "test.run"],
"data_scope": ["project-x/read-only"],
"risk_level": "medium",
"approval_token": "可选审批令牌",
"time_limit": "30m",
"idempotency_key": "防重执行键",
"expected_artifacts": ["test-report", "patch-summary"]
}
本地执行器必须:
- 仅通过出站 mTLS通道领取任务,不暴露公网入站远控端口;
- 校验任务签名、用户身份、设备证书、权限范围和审批令牌;
- 对工具、目录、网络域名、内网系统实施白名单;
- 在时限、资源和权限上限内执行;
- 对高风险动作要求本地确认或云端审批;
- 在设备失管、证书撤销、客户端版本过期或安全基线不合格时拒绝执行;
- 默认将外部网页、邮件、文档视为不可信输入,禁止其改变工具权限与执行策略。
8. 数据、身份与凭证治理
8.1 数据分级
| 等级 | 示例 | 处理原则 |
|---|---|---|
| 公开/低敏 | 通用文案、公开资料 | 可使用公有云模型 |
| 内部 | SOP、一般经营资料 | 权限控制的云端知识与模型网关 |
| 敏感 | 客户、合同、财务、源代码 | 私有网络模型;本地脱敏与最小上下文传输 |
| 核心/受监管 | 支付、生产控制、个人敏感信息 | 原则上不出域;本地/内网处理与人工审批 |
数据边界须覆盖模型输入、附件、向量库、缓存、日志、Trace、下载和分享,而非只覆盖业务数据库。
8.2 身份与凭证
用户身份:谁发起任务
Agent 身份:哪个 Workflow / Agent 执行
设备身份:哪台本地执行器在运行
- 工具调用使用短期、可撤销、范围受限的凭证;
- 不向模型暴露用户密码、长期 Token、数据库密码或密钥;
- 每次工具调用记录发起人、代理身份、设备、资源、权限与结果;
- 重要数据访问与高风险操作需要可追溯的审批责任。
8.3 部署拓扑与降级恢复边界(P1)
上线前应按数据等级和系统位置确定部署拓扑,而不是只决定"是否上云"。
| 组件 | 推荐部署边界 | 关键要求 |
|---|---|---|
| 云端控制面、Workflow、审计 | 企业云账号或专属 VPC | 网络隔离、备份、统一身份与高可用 |
| 模型网关与知识服务 | 与数据等级匹配的企业网络边界 | 模型路由、脱敏、访问日志与存储区域可控 |
| 业务连接器 | 云端专用连接或企业内网网关 | 不直接暴露核心业务系统公网入口 |
| 本地 Agent 执行器 | 受管终端或受管内网节点 | 设备证书、版本管理、安全基线、出站 mTLS |
| Trace、日志与产物 | 与任务数据等级一致的存储区域 | 留存期、下载、分享与删除策略可审计 |
降级与恢复原则:
- 模型服务不可用:规则可完成的 Workflow 继续执行;依赖模型判断的节点暂停、转人工或进入重试队列,不得伪造成功;
- 云端控制面不可用:本地执行器不启动新的高风险任务;已领取任务按租约停止或等待恢复;
- 本地执行器离线:云端 Workflow 保持"等待本地结果"状态,租约到期后按幂等键重派、转人工或交由满足同等权限的备用执行器;
- 业务系统不可用:禁止推进业务完成状态,调用重试、死信队列和补偿/对账流程;
- 恢复后:基于任务 ID、幂等键、业务事件和执行证据进行对账,再决定继续、补偿或人工处理。
9. 可靠性、可观测性与人工接管
9.1 云端业务工作流
- 状态机、检查点、幂等控制;
- 超时、限流、重试和死信队列;
- 跨系统补偿动作;
- 失败后暂停、升级或转人工;
- 流程、模型、工具和数据访问的完整 Trace。
9.2 本地 Harness
- 会话、目录、进程、网络与工具隔离;
- 任务租约、超时中止、断点恢复;
- 本地验证结果、环境版本和执行证据回传;
- 离线时禁止高风险新任务,联网后依据幂等键恢复同步。
9.3 核心指标
| 类别 | 指标 |
|---|---|
| 效果 | 任务成功率、验证通过率、人工接管率、平均完成时间 |
| 流程 | 重复执行率、补偿率、异常升级时长、SLA 达成率 |
| 安全 | 策略拦截率、审批率、权限拒绝率、高风险回滚率 |
| 运行 | 工具调用失败率、客户端健康率、模型/工具/流程/环境故障占比 |
| 经营 | 单任务成本、单位业务结果成本、复用 Skill 的收益 |
10. Skill 资产模型
每个可复用的企业 Skill 必须定义:
输入/输出 Schema
+ 可调用工具
+ 数据范围
+ 权限要求
+ 风险等级
+ 执行位置(云端/本地/内网)
+ 验证方法
+ 回滚或补偿动作
+ 审计字段
+ 版本与负责人
目标是把个人本地 Agent 的能力沉淀为可授权、可复用、可评估、可治理的组织资产。
10.1 Skill 发布质量门槛(P1)
Skill 从"可运行"进入"可上线"前,必须完成以下验证,并将结果归档到 Skill 版本记录:
| 验证类型 | 最低要求 | 未通过时的处理 |
|---|---|---|
| 标准任务验证 | 基于已批准的任务集,校验输出、工具调用和预期产物 | 修复后重新回归,不得进入灰度 |
| 权限与安全验证 | 验证越权请求、提示注入、恶意输入和超范围数据访问均被拦截 | 暂停发布,修复策略/工具边界 |
| 失败与回滚验证 | 模拟工具超时、下游失败、重复任务和中断恢复 | 补齐重试、补偿或人工接管机制 |
| 回归验证 | 新版本不得破坏已通过的关键任务与权限约束 | 回滚至上一稳定版本 |
| 灰度/影子运行 | 在受控用户、受限权限或影子流量中比对结果 | 达标后扩大;异常时停止并复盘 |
Skill 版本必须明确测试负责人、验证日期、适用执行面、风险等级和回滚版本。
11. 建设路径
11.1 样板场景准入卡与验收门槛(P1)
每个样板在开发前必须由业务、IT 与安全共同完成一张"场景准入卡"。未完成准入卡的场景不得进入生产试点。
| 字段 | 必填内容 |
|---|---|
| 业务 Owner / IT Owner / 安全 Owner | 对价值、运行和风险分别负责的人 |
| 业务目标与人工基线 | 当前步骤、耗时、错误/漏办情况和任务量 |
| 目标与验收周期 | 预期改善指标、观测周期与验收日期 |
| 数据与系统范围 | 数据等级、事实来源系统、允许访问的资源 |
| 允许动作与禁止动作 | 可自动执行、需审批、明确禁止的操作 |
| 验证方式 | 结果校验、抽检方式、证据产物与验收人 |
| 异常与回滚方案 | 失败后的暂停、补偿、人工接管和回滚步骤 |
| 上线门槛 | 安全评审、压测/联调、试运行通过条件 |
统一门槛:
- 准入门槛:业务价值、事实来源、数据边界、权限和人工兜底明确;
- 试运行门槛:在受控数据和受限权限下完成端到端验证,结果可追溯、可回滚;
- 扩大门槛:达到场景预设的效果、质量、安全和成本目标,且不存在未关闭的高风险问题;
- 暂停门槛:发生越权、敏感数据误传、关键状态不一致或无法恢复的异常时,立即停止自动执行并复盘。
阶段一:云端治理与业务 Workflow 样板
建设 Web 工作台、统一身份、模型网关、审批审计、任务状态和一个确定性 Workflow 样板。
推荐优先选择:客服工单分流、经营异常派单或销售线索流转。
阶段验收:完成事实来源矩阵、事件/状态契约、幂等与补偿设计;在限定范围内跑通流程并由业务 Owner 验收。
阶段二:本地 Harness 样板
建设本地执行器、设备身份、任务签名、Sandbox 和工具白名单。
推荐优先选择:代码修复与测试、本地资料处理或内网日志诊断。
阶段验收:设备、身份、权限、任务租约、日志证据和人工确认链路全部可用;任务在限定目录/工具范围内完成且验证结果可复现。
阶段三:跨端闭环
让云端 Workflow 能安全调用本地 Skill,并根据本地验证结果继续工单、审批、通知和复盘。
阶段验收:覆盖执行器离线、模型不可用、下游系统失败和任务重派等故障演练;确认业务状态不一致时的人工接管机制。
阶段四:平台化复制
统一 Skill 注册、版本、权限、评估、灰度、回滚和成本归因,复制到更多部门。
阶段验收:通过标准化的场景准入卡和运行指标开展复制,不以模型调用量或 Agent 数量作为扩张依据。
12. 最终结论
确定、可编排、可云端接入的业务流程,应在云端统一执行;依赖真实环境、需要连续观察、工具调用和验证的任务,应由本地 Harness 受控执行。
最终形成:
云端:企业大脑、业务工作流、模型、知识、策略、审计
本地:强 Harness、真实工具、内网资源、执行与验证
混合:云端编排,边缘执行,结果回流,能力沉淀