AI 速读
Harness 设计核心：REPL 容器抽象、上下文压缩策略、Function Calling 闭环与六大原则。
前一篇拆解了 Agent 的 PPAF 循环与四大工程维度。这一篇从「概念 + 框架」进入工程实践：一个稳健的 Harness 系统是如何一步步设计出来的？
顶层抽象：带边界控制的 REPL 容器#
在架构层面，Harness 的本质可以被抽象为一个带有边界控制、工具路由与确定性反馈的 REPL（Read-Eval-Print Loop）容器。它包裹在 LLM 这个非确定性的「大脑」之外，管理从感知到行动再到反思的完整生命周期：
- Read（读取）：上下文管理器把外部世界（用户输入、API 状态）和内部记忆「翻译」成 LLM 可理解的高度结构化的 Prompt——工程化的「感知」。
- Eval（评估/执行）：当 LLM 生成一个规划（如 Function Calling），调用拦截器捕获该意图并路由到正确的工具执行器，执行过程被严密监控（超时、资源配额、错误捕获）。
- Print（打印/反馈）：工具执行的结果被反馈汇编器组装成结构化的「观测结果」，重新注入上下文，供下一轮「反思」与「规划」。
- Loop（循环）：「读取-评估-打印」不断循环，直到达到目标状态或触发终止条件，构成 PPAF 的核心驱动力。
底层挑战：在无限状态与有限 Token 之间架桥#
Agent 的智能建立在对海量状态信息的理解之上，而 LLM 操作的是一个有限的、线性的 Token 序列。Harness 的核心挑战，就是在「无限」的外部状态与「有限」的上下文窗口之间，建立高效可靠的双向映射。
上下文管理的四种策略#
| 策略 | 核心机制 | 适用场景 | 工程挑战 |
|---|---|---|---|
| 滑动窗口 | 保留最近 N 轮对话或步骤 | 连续性强的短期对话 | 容易丢失早期关键信息（长程遗忘） |
| RAG 检索增强 | 外部知识向量化，按意图检索注入 | 需要引用大量外部静态知识 | 检索准确性、实时性、知识冲突 |
| 按需加载 | 提到特定实体时才加载其详情 | 状态空间大但访问稀疏 | 精确的实体识别与依赖分析 |
| 分层记忆 | 短期（对话）/中期（任务摘要）/长期（向量库）三层组合 | 兼顾短期上下文与长期知识的复杂任务 | 记忆提取融合策略、跨层一致性 |
TIP
上下文管理本质是一系列规约规则的集合：Token 预算紧张时，哪些信息该牺牲、哪些该保留，必须有清晰规则。同时注入边界也很重要——RAG 结果注入在 Prompt 的前、中、后，效果差异很大，要避免「大海捞针（Lost in the Middle）」问题。
Function Calling：从文本预测到物理执行#
Function Calling（FC）是连接 LLM 规划与物理行动的桥梁，它包含一个严密而脆弱的生命周期：
- Schema 序列化：把可用工具列表及参数定义（JSON Schema）序列化后注入 Prompt——这是 LLM 理解自己「能力边界」的唯一途径。
- 触发生成：LLM 进行模式匹配，生成一段遵循特定语法的文本，包含工具名和参数值。
- 确定性反序列化：Harness 捕获文本并解析为结构化调用请求。这是最脆弱的环节——LLM 的生成可能 JSON 格式错误、参数类型不对。
- 观测注入：执行调用，把结果（成功或失败）封装成观测文本再次注入 Prompt，完成闭环。
失败面与降级路径：稳健的 Harness 必须为失败设计出路——反序列化失败时，带上错误信息让 LLM 重试，或放弃 FC 回退到自然语言指令；执行失败时，向用户补充信息，或把错误注入上下文引导 Agent 反思换路。
IMPORTANT
状态分离原则：把 LLM 严格视为一个无状态的计算单元（CPU），所有需要跨轮次保持一致的状态存放在 Harness 控制的外部持久化引擎中。试图靠 Prompt 让 LLM 在长对话中自行维护复杂状态，是反模式——行为混乱、不可预测且难以调试。
三大约束与六大原则#
设计 Harness 时必须直面三大约束：
| 约束 | 现象与影响 |
|---|---|
| 模型能力不完备 | 幻觉、上下文丢失、推理不稳定 → 不能盲目信任输出，必须建立事实校验与行为纠偏机制 |
| 上下文窗口物理限制 | Transformer 的 O(n²) 复杂度、注意力稀释 → 必须主动「构建」上下文而非被动填充 |
| 开放环境不可预测 | 外部工具失效、资源变更、用户干预 → 必须具备异常处理、重试、回滚与动态重规划能力 |
应对之道是六大设计原则：
- 为失败而设计：把异常视为常态，所有组件具备容错、重试与优雅降级能力。
- 契约优先：系统内外交互都由机器可读的契约（Schema、API、Event）定义。
- 默认安全：最小权限、零信任、纵深防御，安全是出发点而非补丁。
- 决策与执行分离：「决定做什么」（规划）与「如何做」（执行）解耦。
- 万物皆可度量：每个行为、每次决策、每份资源消耗都应可度量。
- 数据驱动进化：每次运行都是学习机会，建立采集、标注、回流的闭环。
关键工程位点#
落地上述原则，需要在架构中部署五个关键组件：
| 组件 | 核心职责 | 设计要点 |
|---|---|---|
| 工具网关 | 工具注册、发现、Schema 提供与权限校验 | 动态注册发现、RBAC、Schema 版本管理 |
| 调用拦截器 | 在执行前后注入日志、度量、超时、配额 | AOP 设计、可插拔策略（超时/重试/熔断） |
| 反馈汇编器 | 把裸结果（如异常堆栈）转为 LLM 可理解的结构化观测 | 统一反馈 Schema、堆栈裁剪摘要 |
| 上下文状态管理器 | 管理 Token 预算，决定信息去留 | 分层记忆、基于信息价值的优先级排序 |
| 异常处理器 | 异常分类，指导重试与恢复 | 错误码与恢复策略映射、可配置熔断 |
小结#
设计层面记住三件事：REPL 容器的抽象、上下文的工程化管理、Function Calling 的降级设计。下一篇进入实现层面：分层架构、沙盒、成本与度量。
出处
本系列参考咸鱼《万字长文｜一文弄懂 Harness Engineering》（飞书文档 ↗），结合个人理解拆分整理。核心观点与框架归原作者。