从Prompt到Harness：Agent工程四层能力拆解

一个完整的 Agent 任务不只是让模型给出答案，还要让信息进得来、工具跑得稳、状态接得上、结果验得过。B站一场关于 Agent 工程演进的分享，把这个过程拆成了四层能力：Prompt、Context、Harness 和 AgentOS，并用六个问题串起了从单次问答到多 Agent 协作的完整链路。

这场分享的核心判断是：任务越复杂，真正决定成败的就越不只是模型本身。上下文能抓多少信息、注意力能否聚焦、当前目标数据能否被准确传递、任务状态能否跨轮保存——归根到底，要解决的是容量、精度和连续性三个工程问题。

复杂任务为什么会失控

一次回答只需判断答案对不对；多步任务要处理前后依赖；持续任务则必须支持中断续接、结果验收和经验复用。三者的复杂度不在同一个量级。

随着工具结果和历史消息不断累积，当前目标和有效证据在上下文中的占比会持续下降。一旦出现错误操作，污染还会被反复带入后续步骤，最终让模型越来越难抓住真正重要的信息。分享中举了一个例子：如果让模型重新生成已查询到的 15 条记录，就可能发生漏项、篡改和数据变化。

更稳妥的做法是把完整结果保存为引用，由程序准确交给后续步骤，让模型专注于理解和判断。这也引出了 Agent 工程的第一层能力：Prompt。

Prompt 的能力边界

Prompt 可以从简单的角色设计逐步升级为结构要求和注意力提示，但规则写得再清楚，也替代不了状态管理机制。据分享中的观点，一份可执行的项目说明至少要交代四件事：最重要交付什么、哪些操作可以做、相关材料从哪里获取、结果如何检查、未完成工作如何交接。

问题在于，Prompt 驱动的任务通常只能一路运行到底，任何一步失败都可能让整个流程重新开始。它没有持久状态，无法控制上下文增长，也缺少对工具结果的确定性校验。这就是 Prompt 的能力天花板。

Context Window（上下文窗口）是理解这一层能力天花板的关键概念。它指模型单次推理时能够同时处理的最大 token 数量，包括系统提示、历史消息、工具返回结果和当前输入。窗口越大，能容纳的信息越多，但注意力并非线性分布——位于窗口中间的内容往往更容易被忽略，这就是"迷失在中间"现象。因此仅靠扩大窗口并不能解决信息过载，反而可能稀释关键信号的权重。真正有效的做法是对进入窗口的内容做优先级排序和动态裁剪，把当前目标、必要依赖和关键证据放在模型注意力最集中的位置，其余细节则转为可检索的引用。Context 层工程本质上就是在有限窗口内做取舍，而非单纯追求容量扩张。

Context：信息组织的精确控制

进入 Context 层，工程要做的是在执行前筛选当前目标和必要依赖，在执行中整理大结果与关键发现，需要细节时再通过引用取回证据。它追求的不是信息越多越好，而是每一步都恰到好处。

不同来源的信息膨胀要分开处理。大型结果应先完成保存，再生成可解析的引用说明、边界和摘要；用于接续任务的结构化交接需要具体证据时，按需读取相关片段。这样既能控制上下文，也能保留完整追溯能力。

分享中特别强调，有效的对话压缩不能只概括聊过什么，还要记录任务做到哪里、下一步依赖什么、遇到什么阻塞、关键证据保存在哪里。只有形成结构化交接，下一轮执行才能真正接得上。执行中的信息被分为三类：State 保存参数和步骤输出，Working memory 保存当前目标与关键发现，Transcript 只保留近期交流。

Harness：让执行可检查、可恢复

信息管好了，执行仍然可能失败。Harness 负责记录任务执行到哪里、检查工具结果是否满足目标，并在超时、中断或失败后决定继续、重试、取消还是转交。它把模型给出的行动建议变成可以管理的执行过程。

与其在错误发生后不断修复，不如在设计阶段就让正确路径更容易被程序确定。关键数据让工具返回明确状态，要求模型及时记录发现，并且只要当前步骤涉及相关证据就一并留存。

一次任务由多次执行与返回组成，完整任务可以按照 Plan、Execute、Optimize 持续推进，每个执行步骤内部又经历 Thought、Action、Observation 的小循环。页面断开不必意味着任务停止——前端信息、消息推送、事件重组和后台执行应该彼此分离，即便页面断开，任务仍能继续运行并保存过程。重新连接后根据游标补回缺失的进度和结果，从失败处继续，还要防止重复操作。

Thought-Action-Observation 循环是 ReAct 范式的核心结构：模型先产生推理（Thought），据此选择并调用工具（Action），再接收工具返回的观察结果（Observation），如此往复直到任务完成。这一循环让模型能够根据环境反馈动态调整策略，但也带来两个工程难题。其一是循环可能陷入死锁或无效重试，需要 Harness 设置最大步数与失败判定；其二是每一步的中间状态都需要被持久化，否则一旦进程中断，之前的推理链条就全部丢失。Harness 通过记录每轮循环的输入输出快照，使得任务可以从任意断点恢复，而不仅仅是重启整个流程。理解这一循环结构，也就理解了为什么执行层必须独立于单次会话而存在。

AgentOS：从单 Agent 到协作系统

当任务规模扩大，系统需要同时管理执行环境、运行系统、记忆与语义认知、调度和经验治理。分享建议建设时先划分清楚每层责任，再选择必要组件，小项目无需一开始就搭完整平台。

记忆管理需要区分类型。行业规则、业务知识、个人偏好和当前工作状态属于不同类型的记忆，应分别保存。即便记忆已被召回，也要继续检查权限、适用范围和冲突关系。

经验沉淀有一条清晰的验证链：任务完成后先记录执行条件、过程和结果，再提取带有适用范围与证据的候选经验，最后在新任务中验证。只有经得住重复验证的经验才值得写入长期记忆。执行学习，治理是三件不同的事——执行闭环关心这次任务有没有完成，学习闭环关心失败经验能否改善下一次，治理闭环关心新规则能否安全推广。

多 Agent 协作中常见的调度模式包括中心化编排与去中心化协商两类。中心化模式下，一个 Orchestrator Agent 负责拆解任务并分派给执行型 Agent，适合流程清晰、责任明确的场景；去中心化模式下，各 Agent 通过共享黑板或消息总线交换信息，灵活性更高但协调成本也更大。无论哪种模式，都需要解决任务归属、结果汇聚和冲突消解三个问题。共享记忆若无权限分层，一个 Agent 写入的错误经验可能污染整个系统，因此写入长期记忆前必须经过验证链和适用范围标注。协作调度的工程难点不在于让 Agent 互相通信，而在于让它们在边界内各司其职且不产生级联错误。

从哪里开始建设

这场分享给出的实践路径是：遇到输出偏离要求，查 Prompt 层；任务断档，查 Context 层；数据传递出错或过程无法恢复，查 Harness 层；多个 Agent 相互等待，查协作调度层。先定位故障属于哪一层，再补对应机制。

真正值得建设的 Agent，不只是偶尔完成一次任务，而是能够在明确边界内持续交付。Prompt 负责把要求说清楚，Context 负责把信息组织好，Harness 负责把执行稳定落地，AgentOS 负责管理更大规模的协作。把会做一次变成可以重复交付，这才是 Agent 工程化的意义所在。