AI 速读
Harness 落地视角：控制面与数据面分层、记忆与 Token 流水线、沙盒治理与度量体系。
前一篇讲完设计之道，这一篇站在负责落地平台和基础设施的工程师视角，把 Harness 当作一个完整的运行系统，从架构分层、运行机制、执行治理、度量演进四个角度审视。
架构总览：控制平面与数据平面#
一个成熟的 Harness 通常拆分为两个平面：
- **控制平面（Control Plane）**负责「决定做什么」：任务调度、资源配额、行为规划、策略与权限。
- **数据平面（Data Plane）**负责「如何去做」：Agent 运行实例、状态存储、记忆存储和沙盒执行环境。
在此之上可以进一步抽象出四个功能层级：
| 层级 | 控制平面视角 | 数据平面视角 |
|---|---|---|
| L1 呈现与集成层 | API 网关、事件总线，统一入口对外暴露能力 | 客户端 SDK、Webhook，嵌入业务产品 |
| L2 任务与状态管理层 | 任务调度器、工作流引擎，编排长周期任务 | 状态存储，持久化任务上下文与检查点 |
| L3 Agent 核心引擎层 | 行为规划器、上下文策略器 | Agent Runtime 进程、短长期记忆存储 |
| L4 执行与治理层 | 策略引擎、资源管理器，负责安全与成本 | 沙盒执行框架、工具库 |
落地时可以把 Harness 看成一层「智能胶水」：上接模型 API Gateway，下接沙盒和各类服务，以工程的方式串联各个基建。
核心运行机制#
Agent 核心循环#
Agent 的行为抽象为持续的「观察 → 思考 → 行动」循环：
- 观察（Observe）：感知世界状态——用户输入、工具结果、历史对话、任务进度。
- 思考（Think）：规划器更新目标、拆解任务、选择下一步行动。
- 行动（Act）：执行内部操作（更新记忆、结束任务）或外部操作（调用工具、回复用户），结果进入下一轮观察。
WARNING
生产环境的核心循环不是一个简单的 while (true)。它通常需要与工作流引擎或状态机框架集成，支持暂停/恢复、幂等重试、并发事件处理与长周期任务管理。
记忆分层与 Token 转化#
多数 Agent 通过外挂 memory 承载超出上下文窗口的信息：
| 记忆层级 | 典型载体 | 治理要点 |
|---|---|---|
| L1 感官记忆 | Prompt / 上下文窗口 | 容量小成本高，按规约规则精打细算 |
| L2 短期/工作记忆 | Redis、KV、会话库 | 任务中间状态，TTL/会话粒度治理 |
| L3 长期记忆 | 向量库、知识图谱、对象存储 | 沉淀知识与经验，RAG 按需检索 |
在三层记忆之上，每轮调用前还需要一条 Token 转化流水线：
- 信息源收集：聚合用户问题、短期记忆、长期知识检索结果；
- 相关性排序：按时间、语义相似度等指标打分；
- 压缩与摘要：对冗长低密度内容做结构化提炼；
- 预算分配：按 Token 预算为不同信息类别分配额度；
- 模板组装：用显式标注
[user_request]、[tool_output]的结构化模板拼装最终 Prompt。
**关键思想：把注意力管理变成一个外部工程问题。**与其指望模型自己想清楚该关注什么，不如主动构建上下文，把有限的窗口留给真正重要的信息。
规划模式怎么选#
| 规划模式 | 核心机制 | 优缺点 | 典型场景 |
|---|---|---|---|
| ReAct | 单 Prompt 内交替「思考 + 行动」 | 实现简单，但易迷路、缺长期规划 | 一次性任务、简单工具调用 |
| Plan-and-Execute | 先生成结构化计划，再由确定性引擎执行 | 清晰可审计，但对环境变化不敏感 | 定时报表、数据流水线 |
| 分层规划 | 元规划器拆目标，底层 Agent 各自执行 | 适合极复杂任务，成本高 | 全栈应用开发、自动化科研 |
TIP
默认用 Plan-and-Execute，配合「异常触发重规划」已经足够稳健；只有特别开放、长期的任务才需要多层规划与多 Agent 协作。
执行治理：沙盒、资源与安全#
沙盒的四级隔离#
| 级别 | 隔离方式 | 适用 |
|---|---|---|
| L1 进程级 | chroot / namespaces / seccomp-bpf 限制系统调用 | 启动快，可信内部工具 |
| L2 容器级 | Docker / containerd | 生态成熟，大多数工具执行的默认选择 |
| L3 轻量 VM | Firecracker 等，独立虚拟内核 | 多租户、执行不可信代码 |
| L4 完整 VM | KVM / QEMU | 安全性最高成本最大，极少数场景 |
推荐策略：默认容器级（L2）+ 只读根文件系统；对不可信代码或高敏感数据，引入轻量 VM（L3）。
资源弹性#
- 预算与配额：Token、API 调用次数、CPU 时间分别设配额，支持按「平台/租户/Agent/任务」多层配置；
- 超时控制：所有网络请求和工具执行必须设超时，避免下游卡死拖垮整个 Agent；
- 重试策略：临时错误用带退避的重试，永久错误快速失败上报；
- 熔断机制：依赖连续失败时暂时熔断，防止级联故障；
- 优雅降级：关键能力不可用时退到「弱但安全」的模式，如从「可执行代码」退到「只读 + 建议」。
策略门控#
在「规划器 → 执行层」之间放一个策略门控，每次行动前做最后检查：权限校验（RBAC/ABAC）、敏感数据过滤与脱敏、指令注入防御、审计日志。
度量与演进：让 Harness 在数据中成长#
四组核心指标，用来判断系统是否跑在正确轨道上：
- 任务效能：任务成功率、指令遵循度、工具使用有效性；
- 服务质量：端到端延迟、首次响应延迟、错误率；
- 资源效率：平均 Token 消耗、平均工具调用次数；
- 安全合规：策略拒绝率、安全事件数。
这些指标不是为了凑大表，而是反向驱动演进：任务成功率上不去，回到规划器和上下文策略找原因；错误率和成本居高不下，多半要反查沙盒、配额与熔断设计。
写在最后#
Harness Engineering 从来不是又一个需要顶礼膜拜的「银弹」，而是一套生于实践、归于实践的工程哲学：
当 AI 的代码生成能力一次次突破想象，这套方法论冷静地提醒我们：工程师的核心职责从未消失，而是完成了一次升华——从代码的创作者，变成了创造过程的守护者。
我们从不奢望 AI 永远正确，正如从不指望人类永不犯错。真正的工程智慧，在于构建一个能从错误中持续学习、在不确定性中稳健前行的系统。这套「缰绳」的终极目的不是束缚，而是更安全、更彻底地释放。
出处
本系列参考咸鱼《万字长文｜一文弄懂 Harness Engineering》（飞书文档 ↗），结合个人理解拆分整理。核心观点与框架归原作者。