大模型只是发动机，Harness 才是真正的 Agent 产品

Agent 架构模型

这并非某种绝对标准的 Agent 架构，业界也不存在唯一正确的标准。当一个智能体开始具备长期记忆、深度系统集成并承担关键业务时，这套思维模型能帮你理清系统背后的真正骨架。

行业共识正在形成

过去几个月，AI 落地的前沿产品几乎在同一时间走向了同一种架构哲学。

作为嵌入企业协作环境的 AI 协同产品，Viktor 在 2026 年初完成了由 Accel 领投的 7500 万美元 A 轮融资。它支持连接数千种企业工具，但其核心价值不在于研发了更强的大模型，而在于能够零摩擦地嵌入团队已有的飞书、钉钉或企业微信等沟通界面。

紧接着，OpenAI 在开发者大会发布了 dots：一种拥有独立云端虚拟机、跨应用记忆和多级审批机制的常驻 Agent。你可以在客户端给 dot 安排任务，转到团队聊天群继续跟进，或者直接通过语音下达指令，背后始终是同一个 Agent 在运行。针对永久删除数据等高危行为，系统设置了强制的人工审批规则。Meta 发布的智能体 Muse 同样基于独立虚拟机运行，并在即时通讯界面中直接提供服务。

透过现象看架构，这些产品的技术内核完全一致：

前端交互入口在不断变化（网页、协同办公软件、语音交互），但底层的 Harness（外构支架/受控运行系统） 始终如一：相同的身份标识、记忆库、权限体系、安全沙箱和审批流程。Agent 的可迁移性，本质上是其运行支架的可迁移性。

一句话概括核心逻辑：大模型只是发动机，交互界面只是任意进出的门，而 Harness 才是真正的产品本身。

1. 停止把所有工具一次性塞进上下文

企业级 Agent 最容易踩的第一个坑，就是试图把几千个 API 接口打包塞进模型的 Prompt。

当 Agent 需要对接代码仓库、项目管理看板、云厂商控制台、监控报警系统以及各类内部微服务时，系统往往包含上百个 MCP（Model Context Protocol）服务，对外暴露数千个可调用接口。直接让模型去阅读几千个函数定义来决定当前调用哪一个，是低效且极度脆弱的抽象。

Agent 的推理单位必须从原子指令跃升为操作（Operation）——即意图单位（例如「统计本月云资源开销」或「创建工单」），而非机械的底层指令（如 click_tab()）。

一个意图操作通常有三种工程落地形式：

原子工具（Tool）：直接对应单次 API 调用。
复合工具（Composite Tool）：多步编排固化在 MCP 服务端代码中，模型调用一次，获得确定性输出，便于风控审计。
技能（Skill）：由自然语言操作规范组成，指导模型按特定流程组合多个工具完成任务。

通常的演进路径是：复杂意图最初以「技能」形态被模型探索执行；一旦流程沉淀且高度关键，便将其“编译”为确定性的「复合工具」。

在架构上建立分层过滤机制：

能力（Capability）：按业务系统分组（如 AWS、看板系统），是鉴权与准入的边界。
工具（Tool）：带 Schema 的原子动作。
技能（Skill）：工具组合的规范指南。
操作（Operation）：面向 Agent 的最终语义单元。

通过渐进式检索（Progressive Disclosure），Agent 仅根据意图检索对应的操作，避免在上下文内堆砌冗长 Schema。

2. 知识同样需要渐进式加载

区分「知道什么」与「如何去做」，是规避 Prompt 混乱的前提：

记忆（Memory）：我们掌握哪些事实？
技能（Skills）：我们的业务流程是什么？
能力（Capabilities）：我们能访问哪些外围系统？
工具（Tools）：底层具体可执行的接口是什么？
操作（Operations）：Agent 当前真正发起的动作是什么？

成熟的智能体往往沉淀了数百套规章流程（从故障排查、发布变更到代码审查规范）。如果将全部规程塞入系统提示词，必然引发注意力涣散。正确的做法是：仅在 Prompt 中暴露技能名称和一句话摘要，只有当任务明确匹配该技能时，才按需加载完整规范进上下文。

3. 记忆系统必须分层解耦

简单的「对话历史总结并无限追加」只适用于玩具 Demo，在企业级生产系统里难以为继。

生产级记忆体系至少包含三个模块：

工作上下文（Working Context）：当前窗口内的有效信息。
长期记忆（Durable Memory）：沉淀下来长期有价值的事实。
检索体系（Retrieval）：精准提取对应事实的能力。

对话记录不是记忆，从对话中提炼出的残留价值才是。

记忆的构建应遵循以下机制：

混合检索：系统在前置环节自动检索团队全局规范注入上下文；在执行中，模型拥有显式的 search_memory(query) 工具，按需补全上下文。
异步规整管道：当用户声明规则变更时，提炼、去重、归一化与持久化的过程应当在主任务循环外异步完成，不占用实时交互延迟。
严格的作用域划分：必须明确区分用户偏好、工作区规则、项目临时上下文和业务流程规程。一个项目的权宜之计绝不能无序渗透为企业全局策略。

4. 上下文筛选不等于内容生成

向量检索出 40 个候选片段、25 个工具和 12 项技能后，传统做法要么强行全塞，要么再调一次昂贵的大模型去挑选。

这暴露了一个关键盲点：筛选不是生成任务。

在 Harness 内部，存在大量分类、路由与重排决策：搜索哪个命名空间？选用哪个工具？是否需要唤醒大模型？这类任务更适合交给轻量级的判定模型（Decision-oriented Models）或专用分类器。

上下文决策流程

不要因为前沿推理模型「能做」分类，就把所有低级判定都扔给它。在推理模型介入前，利用专用模型或确定性规则将决策空间大幅收窄，既能节省海量 Token 和响应延迟，又能让大模型的算力真正用在深度推理上。

5. 代码执行重塑工具编排

让模型在对话里一步步串行调用接口，处理 500 条跨系统数据时既慢又脆弱。

更优雅的解法是：模型负责理解任务并编写一段脚本，将脚本丢入沙箱环境执行。

customers = crm.search_customers(status="active")
results = []  
for customer in customers:  
    invoices = billing.list_invoices(customer_id=customer.id)  
    overdue = [i for i in invoices if i.status == "overdue"]  
    if overdue:  
        results.append({"customer": customer, "invoices": overdue})

大模型统筹业务流，执行沙箱负责跑循环和批量调用，最后仅将处理结果返回模型。

这意味着执行沙箱不再是外挂计算器，而是 Agent 的数字工作台——配备文件系统、Python 运行时、临时数据库与工具代理。这也是领先的 Agent 产品均配备专属云端虚拟机的根本原因。

6. API 优先，视觉操作垫后

计算机视觉操作（Computer Use）固然吸睛，但不应取代稳健的结构化接口。如果能通过一次 API 完成对账单的调取，去驱动浏览器点击 6 个网页页面不仅效率低下，还会引入极高的失败率。

合理的能力层级应当是：

结构化 API / MCP（首选）；
代码沙箱执行（负责多源组合与数据处理）；
浏览器 / 屏幕操作（兜底手段，用于老旧无 API 系统或纯 UI 流程）。

7. 凭证物理隔离与策略门禁

绝对不要将 API 密钥、数据库账密直接放进模型上下文。模型只需表达意图，具体的调用凭据必须托管在底层的安全网关中。

安全策略架构

同时，策略引擎（Policy Engine）必须横亘在意图与执行之间。模型决定做某事，不等于系统应该盲目执行。需要建立分级风控：

只读操作：直接执行；
低风险写操作：执行并保留审计追踪；
敏感写操作：二次确认；
高危 / 破坏性操作：强制人工介入审批。

执行链路永远是：模型意图 → 操作匹配 → 策略校验 → 权限鉴权 → 风险评估 → 执行或等待人工。

8. 人机协同是底层协议，不是前端 UI

当 Agent 准备在生产环境执行服务升级时，脆弱的设计是在聊天框里打印一句「是否继续？」，然后祈祷模型能准确理解用户的后续回复。

严谨的架构应当由 Harness 抛出一个结构化的待决操作（Pending Action）。客户端渲染出真实的审批卡片（通过 / 拒绝），用户的点击直接恢复被暂停的执行状态机。

必须明确：高危操作的人工审批，是由底层安全策略强制挂起的，绝不能依赖大模型自己“主动发问”。 人机协同属于协议生命周期的一部分，而不是前端的文本修饰。

9. 动态模型路由

面对成千上万个任务，全部无脑调用超大规模推理模型是极大的资源浪费。Harness 应该承担路由分发器的职责：根据任务复杂度、风险等级、延迟要求与成本，动态将请求分发给轻量模型、代码专用模型、多模态模型或高级推理模型。

10. Agent 绝不能绑定单一渠道

很多 Agent 最初只是一个飞书机器人或钉钉插件。当业务需要扩展到微信公众号、网页端或独立桌面端时，往往面临重构整个代码库的窘境。这说明通信渠道与 Agent 核心运行时耦合严重。

合理的解耦方案是将渠道完全视作适配层（Adapter）：

多渠道解耦架构

外部消息一律解析为标准化的内部事件对象进入 Harness；离开时，再由通道适配器转换为主机支持的富文本卡片或语音。核心逻辑与记忆系统永远不动，移动的只是接入端口。

11. 长程任务的持久化状态机

如果任务需要持续运行数小时甚至数天，「单次 HTTP 请求对应一次 Agent 任务」的假设便彻底失效。长程任务依赖持久化运行状态：当前计划、执行进度、产物缓存、挂起状态与检查点（Checkpoints）。

这时的 Agent 基础设施更像是一个以大模型为核心控制循环的分布式状态机，能够在等待审批、等待异步回调的过程中随时挂起并在任意时刻无缝恢复。

12. 以轨迹为单位的可观测性与评测

传统监控关注接口响应时间与 HTTP 500 报错，而 Agent 的监控单元必须转变为执行轨迹（Trajectory）：

任务目标被解析成了什么？
检索了哪些上下文片段？加载了什么技能？
触发了哪些风控策略？执行了哪段沙箱代码？在何处失败并如何重试？

评测系统检验的是一整套复杂系统：

$$\text{模型} + \text{上下文} + \text{记忆} + \text{技能} + \text{工具} + \text{策略} + \text{沙箱执行} = \text{最终 Agent 行为}$$

单纯测试模型的基准分毫无意义，系统的真实表现取决于整套支架对模型的引导与约束效率。

聚合视角：模型面向的极简接口

当底层架构完成解耦与封装后，暴露给核心大模型的交互界面会收敛得极为克制：

search_memory(query)
list_capabilities()
search_operations(query, capability?)
load_operation(id)
execute_operation(id, args)

run_code(code)
delegate_task(task)
ask_human(question, options?)

在这些简洁的原语之后，可以承载成百上千个微服务和工具，数以百万计的记忆片段，以及严密的风控策略。复杂度依然存在，但它被妥善隐蔽在渐进式抽象背后，而不是无脑糊在提示词里。

大模型能力固然关键，但随着模型间差距不断收敛，替换一个底层大模型往往只需要改动几行业务配置；而承载企业专属知识、权限边界、工作流定义与风控体系的 Harness，才是无法轻易被替代的产品护城河。

评价一个 Agent 方案的成熟度，不必过分执迷于它背后模型的参数量，先看看它周围搭建了一套怎样的工程支架。