引言Model+Harness=Agent：从模型意图到可验证生产动作

Agent是未来所有生产工作的绝对主体，核心链路是AGI完成智力加速计算，并通过Harness系统接入可操作、可控制、可验证的Interface of the physical world来完成工作。

当前所有的Agent应用基本都符合该框架，通过不断强化Model的复杂工作推理能力、Interfaces的数量/覆盖面、Harness的效率/控制粒度，来提高应用的使用价值。

Model本身不直接改变外部世界，它每一次inference都是在冻结的知识与推理空间中完成一次性的高维计算流。这个计算流可以产生回答、计划、JSON、toolcall，但这些输出在进入外部系统前都只是意图，不是执行事实。

所以Agent不是简单的Model+Tools，Tools只是外部interface的入口，真正决定Agent能力上限的，是Harness能否把模型意图转成受控动作，并把动作转成可验证事实。

1.Model：高维计算流与外部事实边界

在当前Transformer骨架下，Model可以理解为一个由大规模人类知识、代码、语言、交互模式压缩得到的超高维隐空间。

Pre-training建立通用知识和模式压缩，通过Scaling Law与Transformer Block的架构优化：

I.不断提升整个隐空间的知识覆盖度与对客观正确性的逼近度与精度。

ii.不断提高隐空间的逼近效率/Token。

iii.不断降低推理的隐空间寻路成本/Token。

Post-training在Pre-Training的基础上，通过Domain data优化局部特定的隐空间结构，使模型获得更高的Domain marginal intelligence/token。

加速解决人类现实世界复杂智力问题的根本需求，天然会反过来要求Model自身不断增强以下能力：

Context Window：

i.不断扩大每一次高维计算的信道容量，容纳更多的历史信息。

Ii.不断优化输入/输出数据的结构来提高固定Context Window下的输出效率（最大化信道传输效率）。——输入输出Sequence结构、缓存设计。

Reasoning/Planning：

i.将人类的复杂推理逻辑过程内嵌到Model隐空间内-COT。

ii.放大COT的高维计算规模来获取更高精度的输出。

Structured Output：

把隐空间计算结果转换成外部系统可解析的数据结构，JSON/schema是最基础的外部系统接口，解决“模型输出如何被外部系统消费”。

Tool Call：

模型从回答问题进入操作环境的基础形态，Tool call表达的是“模型想调用什么能力、传入什么参数、期望什么结果”。

这四类能力都在增强Model对外部环境的可接入性，但它们仍然不等于执行。

Model每一次输入–输出，本质上是在冻结知识隐空间内完成一次一次性高维计算流，它可以判断、计划、请求操作，但不能直接作用外界环境。

因此，Model侧的边界可以写成一个contract：

1.模型可以提出行动。

2.模型无法拥有外部真相。

3.工具调用是意图，而非执行。

4.补全文本并非任务结束。

这就是Harness Engineering的必要性：把模型意图和真实生产环境之间的断层补上。

2.Interfaces：人类生产环境的交互界面

标题里的physical world，不是狭义物理空间，而是人类真实工作的整体环境，它已经高度数字化：文件系统、OS、terminal、browser、Office、IDE、数据库、企业软件、API、MCP server、云服务，以及这些系统背后的权限、状态、流程和审计。

过去几十年ICT基础设施的演进，本质上是把计算机生产环境一层层封装成interface：

1.硬件层：用二进制信号表征、计算、存储和传输生产数据。

2.驱动/固件层：封装硬件能力，对OS/kernel提供低层ABI和控制接口。

3.OS/kernel层：用进程、线程、文件系统、网络、IO管理构建标准化控制体系，对应用软件提供资源抽象。

4.应用软件层：把具体生产场景封装成UI、API、CLI、plugin和workflow。

5.业务系统层：在应用之上叠加权限、状态、流程、数据模型和审计。

以上均通过计算机环境的语言体系（机器码、汇编语言、高级语言构建的程序世界）实现分层控制交互。

这些interfaces的交互主体以往只有人，但未来Model会成为绝对主体，原因如下：

1.Model与计算机接口底层表达形式一致，天然实现更高交互带宽、更全面交互范围（数据IO效率）。

2.Model单体有指数级知识体量，驱动智能加速计算（数据计算效率）。

3.Model天然可以实现复制、并发。（数据IO、计算的整体规模）

4.基于Amdahl‘s Law，如果一个生产流程的核心瓶颈是智力工作，提升效率的最优方式就是尽可能放大Model的过程权重。

5.在4的基础上，人类必然会开放越来越多的interfaces供Model对接交互。

这就引出最关键的问题：Interfaces越来越多、层次越来越丰富，如何高效控制Model与interface的交互过程，并不断提升交互效率（任务Token成本）？

解决这个问题，就需要构建Harness Engineering——不是开发单个tool adapter，而是实现对interface的统一控制。

3.Harness：运行在计算机OS之上，供模型使用的操作系统

Harness可以理解为运行在OS上的一类模型控制进程。它不替代OS，但它为Model定义了一套通用任务生命周期，使模型能够以受控方式观察、决策、行动、验证和结束。

一次Chat/TASK的Harness生命周期可以拆成：

3.1解析用户输入

Harness先解析用户输入：goal、mode、references、source guidance、artifact target、model config、context policy。用户给的是自然语言意图，Harness要把它转成runtime可消费的数据结构。

3.2构建运行边界

Harness决定任务边界：workspace root、tool disclosure、capability set、permission policy、timeout、budget、approval policy、rollback policy、sensitive data disclosure。这个阶段决定模型能看到什么、能调用什么、能改什么。

3.3构建模型输入

Harness构建初始模型输入：system prompt、user prompt、context pack、tools schema、domain prompt、model config、历史状态摘要。这里的核心不是“写prompt”，而是把任务现场编码成模型可计算的输入。

3.4维护模型通信链路

Harness维护与ModelAPI的通信链路：streaming、retry、timeout、schema validation、provider transcript、tool-call protocol，Provider返回的任何tool call都先进入意图层。

3.5启动AgentLoop

-POST prompts。

-接收并解析model response。

-将provider native tool call映射到registered capability。

-做参数校验、权限校验、workspace boundary校验。

-执行tool/capability。

-记录tool result、receipt、artifact、raw result ref。

-根据新事实重建下一轮context。

-继续loop，直到模型通过Harness提供的closure tool主动结束。

这里的关键点是：

1.模型只能提出action，Harness决定action是否可执行，runtime负责执行，truth ledger负责记录。

2.任务结束不应该由普通assistant content决定。Harness必须提供明确closure tool。这一步本质是任务完成账本。没有closure tool，Agent很容易在长程任务里提前宣布完成。

3.6处理失败和恢复

网络错误、schema错误、权限阻塞、tool参数错误、terminal timeout、context overflow、artifact audit failure、用户取消，都应该作为failure event记录。任务结束后，Harness还要释放子进程、更新run state、保存even tlog，并把最终状态投影给产品层。

综上，Harness Engineering的核心不是堆工具，而是定义一次任务如何合法开始、如何被执行、如何被证明、如何失败、如何恢复、如何沉淀为后续迭代数据。

4.常见Agent概念在Harness生命周期中的位置

很多Agent领域概念，本质上都可以放回Harness进程生命周期中理解。

Tool Use是模型调用外部能力的结构化入口。工程重点不是tool数量，而是tool的能力域、参数contract、权限边界、执行receipt和失败语义。

Planning通过prompt、route或controller要求模型按特定模式分解任务；Planning只是意图组织方式，不能替代执行事实。

Skills是domain prompt、流程约束和工具使用经验的封装。它解决局部任务稳定性问题，但仍然依赖Harness的tool/runtime/truth。

MCP是外部工具服务接入协议，它把Harness进程外的工具服务标准化暴露给模型或Agent runtime，但它不自动解决权限、证据和任务闭环问题。

Memory对历史loop、用户偏好、任务结果、失败经验做结构化存储、检索和压缩，再作为后续context输入。Memory的关键不是“保存聊天记录”，而是决定什么事实可以被复用、以什么粒度复用、是否会污染当前任务。

Subagent为当前Harness提供启动子Harness的能力。真正难点不在“多开一个模型调用”，而在子进程生命周期、context分配、文件并发写锁、IPC、失败传播、结果合并和责任归属。

Multi-Agent可以是多个Harness进程协作，也可以是产品层多个隔离任务并发。难点是调度、隔离、共享状态、冲突处理和evidence合并。

这些概念如果脱离Harness生命周期，容易变成单纯的功能堆叠；放回生命周期里，它们才是工程化的Agent系统模块。

5.SuperNova：从provider tool call到receipt-backed execution

SuperNova是我为了吃透AgentHarness领域实践开发的桌面端Agent应用。

可直接下载windows安装包使用：https://github.com/Ray-Code-Svg/SuperNovaAgent.git

核心链路是：

Workbench->LocalRuntimeProtocol->ProductRuntime->ProcessKernel->ProviderToolCall->RegisteredCapability->Receipt->ProcessTruth/ChatTruth->ProductProjection->UI

这条链路里，每层都有明确分工，且只拥有自己的source of truth：

Workbench是用户操作面：

它负责workspace/container选择、

Chat/TASK模式、

composer、

source picker、

artifact target、

model/context config、

message stream、

task rail、

artifact card、

用户干预。

它只消费projection，不拥有executiontruth。

Local Runtime Protocol是UI和runtime之间的typed boundary：

workspace、container、chat、task、artifact、run、stream、settings、model_config、context_pack都通过DTO和stream event对齐。

Product Runtime是产品运行层：

它负责AxumHTTP/SSEroutes、ProductDB、run_registry、message_feed、projection_shards、runtime_event_log、Kernel Bridge和Kernel Worker；它维护用户可见的read model和run state，但不替代Kernel truth。

ProcessKernel才是执行事实层。

ChatRuntime写ChatTruth；

RootProcess+TaskAgent管TASKloop；

ModelRuntime+DeepSeekModelProvider处理provider native tool calls；

Registered capability runtime执行OS、terminal、office、data、artifact、package、client_env等能力。

这套结构里有几个不变量：

1.provider native tool call是模型意图，不是执行事实。

2.文件变更、命令执行、文档处理、包构建必须经过registered capability。

3.capability成功或失败都要写receipt。

4.TASK的完成不能靠普通assistant answer，而要通过process.complete写入completion ledger。

5.UI看到的是projection；真正的事实来自ProcessTruth、ChatTruth、receipt、artifact和replayable event。

例如，一个TASK想生成并验证交付物，模型可以提出os.write_artifact等工具意图；但只有Kernel在workspace boundary和capability token下完成执行、写入receipt，并经过closure gate检查后，任务才可以被认为完成。

6.SuperNovaAgent开发历程复盘

耗时4个月；

一共96个仓库CheckPoint；

共消耗40亿左右Tokens；

模型使用GPT5.3~5.5；

推理强度保持超高；

维护长期handoff文档、dev_imple文档用于为Model提供完整历史context；

总订阅成本260$。

开发历程：

3次Harness Engineer架构重构：

阶段一：使用LangGraph框架构建Harness状态机，但没有构建Harness各组件的数据Contract，Model陷入无序推理，无法完成任何任务。

阶段二：使用LangGraph框架构建Harness状态机，构建了数据Contract，Model能获取真实环境输入，推理开始有效，但陷入了Case Family的伪Agent架构，本质上是workflow，无法完成通用任务。

阶段三：补充学习了OS知识，理解了程序的进程本质，重新设计了基于进程生命周期控制的Harness Kernel架构，规模抽象底层直接调用OS Native API的Tool Capability，构建DeepSeek Native Tool Call的Adapter层。

1次桌面端产品架构重构：

阶段一：配套阶段1,2的HarnessKernel，用于测试验证，存在众多python胶水层。

阶段二：通用HarnessKernel实现后，历史胶水层接口已混乱，无法承载桌面端产品闭环，重新设计了桌面端UI+ProductRuntime+LocalRuntimeProtocol+HarnessKernel的分层架构，以Harness Kernel作为整个产品的唯一运行时Source of Truth，分层之间定义清晰DTO Contract。

1次开发语言选型切换：

HarnessKernel阶段一、阶段二都使用python，阶段三切换到Rust；

桌面端产品重构时，使用React/Vue构建前端UI，产品服务端整体都使用Rust。

原因：Rust作为编译型语言，在复杂项目集成，大规模代码工程开发、规模化单元测试、集成测试时，Cargo test能提前有效定位代码漏洞，便于代码全局的问题定位与收敛闭合。

UI/UX原型设计：

1.为达到商业级桌面端的UI/UX体验效果，自己手绘了UI/UX原型图。

2.总体原则是：UI/UX是产品全量功能的精确投影，而不是视觉元素的堆砌，要避免给用户造成任何注意力浪费。

3.最终桌面端呈现效果

测试验收：

1、服务端测试自动化：先针对Harness Kernel开发了覆盖全量Agent底层能力的通用TASK Test Matrix，每次都自动跑全量case，然后从人类用户的结果接受度、Case执行的健康度遍历检查全量Case的测试日志；划分问题类别，最后分批做修复，循环整个loop直到达成开发目标。

2、桌面端手动测试：构建真实桌面端安装环境下的workspace测试区，设计通用Test Matrix，覆盖UI/UX的功能/性能测试，手动测试安装后的桌面端应用，并手动记录问题日志，结合产品服务端测试的运行日志让Codex进行修复loop。

3、Agent开发暴露的测试问题类别：

1.Context failure：模型没有看到关键文件、历史状态被压缩错、引用粒度不对。

2.Tool schema failure：schema设计不稳定，模型经常传错字段或误解参数语义。

3.Policy failure：权限太松导致风险，太紧导致任务无法推进。

4.Runtime failure：terminal timeout、子进程挂死、provider error、network retry、service lifecycle不一致。

5.Projection failure：Kernel truth已更新，但ProductRuntime或UI没有正确显示。

6.Artifact quality failure：产物存在，但内容空泛、模板化、coverage不足或没有满足用户真实目标。

7.Closure failure：模型过早完成、无法完成，或者completion statement和receipts不一致。

桌面端RC0版本功能如下：

1.Winodws安装包，配置API后安装即用。

2.API加密保存，不暴露。

3.支持多workspace*多container任务并发，支持container归档/恢复。

4.批量读workspace文件并回答用户问题（Chat模式）

5.workspace内执行和产出结果（TASK模式）

1）在workspace边界内修改文件、生成文件、复制/移动/重命名/删除文件。

2）通过Terminal运行有边界命令，或启动、检查、停止本地服务。

3）读取、创建、校验、改写DOCX等办公文档。

4）读取和处理CSV/dataset，并导出CSV或Markdown结果。

5）生成Markdown、JSON、TXT、CSV、DOCX等用户可见交付物。

6）打包输出zip，并生成manifest、checksum等辅助文件。

7）在任务结束时给出completion statement、产物列表、关键来源和已知限制。

8）使用@命令符精准指定Agent参考特定源数据。

9）精准配置Model SKU、Reasoning强度、OutputTokenBudget。

10）精准控制历史Chat/TASK上下文注入。

11）支持长程TASK内自动压缩历史上下文。

12）支持用户观察每一次API请求的Context使用情况,估算上下文注入的Context占用。

7.后续可继续深入探索的Harness趋势

从未来AI应用与人类用户需求出发，Agent绝对不仅是单纯的工具，而可能成为人类用户在数字世界的镜像Entity，不单单能完成任务，而且能代表用户在数字世界行动，这样才能让AI真正加速经济活动（摆脱人类单体思考带宽的限制），从这个方向出发，Harness还有以下可拓展方向：

1.围绕Agent Entity的：

身份协议：Agent是谁，代表谁？

授权协议：Agent能做什么？

记忆协议：Agent继承什么，不继承什么？

任务协议：Agent如何接受、分发、交接工作？

验证协议：Agent任务结果如何验收？

审计协议：Agent行动历史如何追踪？

结算协议：Agent产出的价值如何交换？

冲突协议：Agent出错和争议如何处理？

2.Agent Entity实现相互通信，需要构建面向Agent的分层通信协议与软件栈。

3.Agent Entity的集群化与Sharing Contexts Management。

4.Agent Entity的主动行为能力（不是固定模式的定时任务），比如主动根据Memroy/Context向用户提出建议等。

5.为Agent Entity构建一套经济生态系统，让Agent代表用户在数字世界进行经济交易，互联网已经解放了人类个体经济活动的空间/时间限制，而Agent将彻底释放人类个体思考带宽的瓶颈，实现规模并发。

8.总结

综上，我对Agent Harness的理解概括为：

Harness is the OS for Model to work in the physical world.

Harness让Model从“高维知识计算器”进入“可验证的生产动作系统”，Agent的关键不只是模型多聪明，而是模型意图能否在真实环境中被控制、执行、证明、复盘，并最终通过真实任务循环推动Harness和Model共同进化。

欢迎下载windows安装包体验SuperNovaAgent：https://github.com/Ray-Code-Svg/SuperNovaAgent.git