本文系统拆解了 LLM 智能体背后的工程系统 Harness，从循环机制、工具设计、上下文工程、长程任务、多智能体编排、安全护栏六个维度，结合 Anthropic、OpenAI、Google 三家公司近两年的公开工程资料，解析 Harness 的技术原理。文章通过 SVG 架构图、功能图与交互时序图，层层还原其内部机制，并探讨了不同公司在 Harness 设计上的方法论与工程实践。对于想要了解大模型智能体如何运作，并希望提升模型可靠性的程序员来说，本文提供了宝贵的参考与收藏价值。

1. 为什么"模型"不等于"Agent"

---

一个常见的误解是：把模型从 GPT-4 换成 GPT-5，或者从 Claude Sonnet 换成 Claude Opus，Agent 就会自动变强。但三家公司的工程博客几乎给出了同一个反例。Anthropic 在《Effective harnesses for long-running agents》中做过一次对照实验：把当时最前沿的编码模型 Opus 4.5 直接放进 Claude Agent SDK 的循环里，只给它一句高层指令——“做一个 claude.ai 的克隆网站”——即便 SDK 本身已经内置了上下文压缩（compaction）能力，模型仍然会在多个上下文窗口的交接处反复失败。这说明压缩这类"通用能力"并不足以让 agent 稳定完成复杂任务，真正起决定作用的是外围那套工程脚手架。

Anthropic 在更早的《Building Effective Agents》里给出了这套脚手架存在的理论依据：他们把所有"由 LLM 驱动的系统"统称为 agentic systems，但在其中划出一条关键分界线——Workflow是"LLM 与工具被预定义的代码路径编排"的系统，剧本是人写的，模型只是演员；Agent则是"LLM 动态地自主指挥自己的流程和工具使用方式"的系统，剧本由模型在运行时自己写。这条分界线直接决定了 harness 该往哪个方向设计：workflow 的 harness 重点在"编排的确定性"，而 agent 的 harness 重点在"如何让模型的自主决策保持在正确的轨道上"。

OpenAI 的《A practical guide to building agents》给出了工程上更具体的三要素拆解：模型（负责推理判断的大脑）、工具（连接真实世界 API 与系统的手脚）、指令（定义目标、边界与行为规范的说明书）。这份指南特别强调，对于没有 API 的老旧系统，agent 甚至可以借助 computer-use 模型直接操作网页和应用界面，就像人类一样点击、输入——这意味着"工具"这一层的边界正在从"结构化 API"扩展到"任意可视化界面"。

Google 在 2024 年的白皮书《Agents》里，则把这套系统拆成三层：模型层（Model）、编排层（Orchestration）、工具层（Tools）。其中编排层是让 agent “像 agent” 的核心——它管理一个观察-推理-决策-行动的循环，让模型能够遵循 ReAct、Chain-of-Thought、Tree-of-Thoughts 等推理框架驱动自己的行为，而不是被代码里的固定分支牵着走。

把三家公司的表述叠在一起看，可以提炼出一个通用定义：

Harness = 模型之外的全部工程基础设施，包括系统提示词与行为规范、工具定义与执行通道、循环控制与状态机、上下文管理与记忆持久化、以及安全护栏——它们共同决定了"同一个大脑"在真实世界里到底能不能干成事。

下面这张架构图完整呈现了这套系统的分层结构：

图 1：Agent Harness 整体系统架构——编排层、上下文管理、工具层、护栏共同环绕在 LLM 推理核心周围，最终落地到真实世界的外部系统。

这张图里有两个容易被忽略、但在实践中至关重要的细节：

第一，LLM 核心在中间，而不是顶端。这不是审美选择,而是在暗示一个工程事实——harness 里的每一层都在为 LLM 的"下一次推理"服务:编排层决定它什么时候该停、什么时候该继续;上下文管理决定它这一刻能看到什么信息;工具层决定它能对世界做什么;护栏决定它有多大自主权。模型本身只是这套系统里被反复调用的一个"纯函数"。

第二,外部世界那一层是虚线连接的。工具调用真正落地的地方——API、代码仓库、数据库、浏览器——都不在 harness 的直接控制范围内,harness 只能通过工具这一层"伸手"过去。这也是为什么 Anthropic 在《Writing effective tools for AI agents》里反复强调工具设计要"像给同事写文档一样清晰"——因为这是模型认知与真实世界之间唯一的接口,这层接口的质量直接决定了整套系统的天花板。

---

2. Agent 循环:控制权到底在谁手里

---

如果说架构图回答的是"harness 由哪些部件组成",那么下一个问题是:这些部件是如何在时间维度上协同工作的?答案是一个不断重复的循环。

Anthropic 在《How we built our multi-agent research system》里,把这套循环描述为OODA 循环(Observe, Orient, Decide, Act,源自军事决策理论):子智能体反复执行"观察当前已收集到的信息与仍需获取的信息、面向可用工具与查询进行定向、基于已有认知做出使用某个具体工具的决策、然后执行该工具调用"这四个动作,直到任务完成。文章中给出的定义非常朴素——多智能体系统就是"多个自主地在循环中使用工具的 LLM"协同工作,这也是 Anthropic 对 agent 最简洁的工程定义:tools in a loop。

用伪代码来表达这个循环,大概是这样:

context = [system_prompt, tool_definitions, user_task] while True: response = LLM.generate(context) # ③ Decide：模型自主决定下一步  if response.type == ”final_answer”:   return response.content # 循环终止条件由模型自己判断  if response.type == ”tool_use”:   tool_result = execute_tool(response.tool_call) # ④ Act：Harness 执行真实调用 context.append(response) # 把模型的决策写回上下文 context.append(tool_result) # 把工具结果写回上下文（① 下一轮的 Observe）  if context_usage(context) > COMPACTION_THRESHOLD:   context = compact(context) # 上下文管理介入，防止预算耗尽

这段伪代码揭示了一个所有三家公司都反复强调的关键事实:循环退出的判断权在模型手里,而不是在代码里。Harness 不会在第 N 轮强制掐断对话,它只负责"翻译"模型的决策(把 tool_use 请求变成真实的 API 调用),以及在幕后维护上下文预算。这正是 Anthropic 区分 workflow 与 agent 的分水岭在代码层面的体现——workflow 的终止条件写在 if/else 里,agent 的终止条件"长"在模型的推理过程中。

下面这张功能图把 OODA 循环的四个阶段和它们各自消费/产出的信息可视化出来:

Agent 循环功能图：Observe → Orient → Decide → Act 每一圈循环，模型都在消费上一轮留下的上下文，并产出新的上下文供下一轮使用

图 2：Agent 循环功能图——观察、定向、决策、行动四个阶段循环往复，中心的上下文窗口是整个循环唯一的"共享内存"，且预算有限。

这张图的中心是一个深色的"黑盒":上下文窗口。四个阶段本质上都在读写这同一块有限的内存——这也是为什么接下来两节要分别深入"工具"(决定行动的落地能力)和"上下文"(决定观察与定向的信息质量)这两个最容易被低估的 harness 组件。

2.1 工具设计:接口质量决定认知天花板

Google 的白皮书把工具分成三类,这个分类框架目前仍然是业界描述工具层最清晰的方式之一:

• Extensions(扩展)

模型与 API 之间的直接桥梁,由模型自己决定何时调用、如何拼装请求参数,执行也由模型侧完成。

• Functions(函数)

模型只负责生成调用某个函数所需的结构化参数,真正的执行发生在客户端代码里——这给了开发者在"模型决策"和"真实执行"之间插入校验逻辑的机会。

• Data Stores(数据存储)

面向检索增强生成(RAG)的外部知识库,让模型可以在推理时动态获取训练数据之外的信息,而不需要重新训练或微调。

Anthropic 在《Writing effective tools for AI agents》里则从"事故复盘"的角度给出了更接地气的教训:当一个 agent 同时接入几十个 MCP Server、数百个工具时,如果工具功能重叠或者用途含糊,模型会在"该用哪个工具"这件事上产生真实的困惑,进而拖慢甚至搞错整个任务。他们给出的解法是命名空间(namespacing)——用统一前缀对相关工具分组,帮助模型在心智上划清工具之间的边界,MCP 客户端也常常默认这样做。

更有意思的是,Anthropic 在多智能体研究系统里发现,工具描述本身也可以被 agent 自我优化。他们专门构建了一个"工具测试智能体"(tool-testing agent):把一个存在缺陷的 MCP 工具交给它,让它实际尝试调用、观察失败模式,然后重写这个工具的描述文本以避免同样的错误——这个自我修复的过程把后续任务的完成时间平均缩短了约 40%。这揭示了一个更深层的工程原则:工具描述文档不是写给人看的说明书,而是模型认知系统的一部分,理应像代码一样被迭代和评测。

2.2 上下文工程:比提示词工程更根本的问题

如果说工具决定了 agent"能做什么",上下文工程决定的是 agent 在几十轮循环之后"还能不能保持清醒"。Anthropic 在《Effective context engineering for AI agents》里提出,继"提示词工程"之后,“上下文工程"正在成为新焦点——真正的问题已经不是"提示词该怎么措辞”,而是在模型有限的上下文窗口内,应该保留哪一种"信息配置",才最可能引导出期望的行为。

文章特别命名了一种现象——context rot(上下文腐化):随着上下文窗口被逐步填满,模型保持专注、准确回忆早期细节的能力会系统性下降。这意味着单纯扩大上下文窗口的长度(从 100K token 扩到 1M token)并不能替代精细的信息筛选与管理,过多的、低信噪比的信息反而会稀释模型在关键信息上的"注意力预算"。

结合 Anthropic 在长程 agent 实践中的经验,一套成熟的上下文管理策略通常由四种手段组合而成:

• 压缩(Compaction)

:Claude Agent SDK 内置的能力,对早期的对话历史和工具调用结果做摘要,为后续轮次腾出预算,但 Anthropic 也坦承压缩"并不总能把完全清晰的指令传递给下一个 agent",不能把它当作银弹。

• 检索(Retrieval)

:按需从外部知识库中取出当下真正相关的信息,而不是一次性把所有可能有用的信息都塞进上下文。

• 文件化记忆

:把关键状态写进结构化文件(而不是留在对话历史里),让信息可以跨会话持久化——这正是下一节长程 agent harness 的核心思路。

• 子智能体隔离

:把探索性、消耗大量 token 的子任务交给拥有独立上下文窗口的子智能体处理,只把提炼后的结论带回主上下文——这是下文多智能体架构一节要展开的内容。

把工具调用循环和上下文预算的消耗过程叠加在一起看,可以还原出一次完整任务里"信息是怎么流动、上下文是怎么被消耗"的全貌。下面这张交互图用带泳道的时序图,把 harness、LLM、工具三方在一次真实任务里的往返通信,以及上下文占用率的变化,完整地画了出来:

图 3：大模型 Agent 流程交互图——两轮工具调用循环中，上下文占用从约 30% 涨到约 58%，触及阈值后由 Harness 主动触发压缩。

这张图把"循环机制"与"上下文工程"两节的内容缝合在了一起:③⑦ 两次 tool_use 请求是模型自主发起的决策,Harness 只是忠实地执行了④⑧两次真实调用;而⑥⑩两次"写回上下文"的动作,则直接对应上一节讨论的 context rot 风险——这也是为什么一个成熟的 harness 必须在设计阶段就规划好压缩触发的阈值,而不是等上下文溢出报错才临时补救。

---

3. 多智能体架构:什么时候需要"不止一个 Agent"

---

单个 agent 的循环再精巧,也会在信息空间足够大、需要并行探索的场景下遇到瓶颈——比如开放式的深度研究任务。这正是 Anthropic 在《How we built our multi-agent research system》里详细拆解的场景:Claude 的 Research 功能采用orchestrator-worker(编排者-工作者)架构,由一个 Lead Researcher 负责规划任务、并动态创建若干专职的子智能体(subagent)并行搜索不同的信息面向,各自独立完成检索后把提炼过的结论返回给 Lead Agent 做综合,最后再交给一个独立的 Citation Agent 做单独的引用核对。

3.1 这套架构解决了什么问题,又付出了什么代价

Anthropic 给出的内部评测数据相当具体:多智能体系统相对单智能体 Claude Opus 在其内部研究评测上带来了约90.2%的效果提升,复杂查询的研究耗时降低了约 90%。但代价同样清晰——多智能体系统消耗的 token 量能达到普通单轮对话的约15 倍。团队进一步做了归因分析,发现 token 使用量本身就能解释 BrowseComp 评测中约 80% 的性能方差,工具调用次数和模型选择只能解释剩下的部分——这意味着多智能体架构本质上是在用"花更多 token 铺开更大的探索面"来换取效果,而不是靠某种更聪明的算法取巧。

正因如此,Anthropic 在后续文章《When to use multi-agent systems (and when not to)》里特别提醒:今天很多团队把多智能体架构用在了单智能体本可以做得更好的场景上——他们见过团队花几个月搭建复杂的多智能体系统,最后却发现只是优化单智能体的提示词就达到了同等效果。多智能体真正的适用边界,是可以被拆解成多个相对独立、彼此不需要频繁共享状态的探索面向的任务;而像写代码这种子任务之间强耦合、需要频繁同步上下文的场景,拆成多个智能体反而会因为协调开销而得不偿失。

3.2 从原型到生产:多智能体系统特有的工程教训

比架构本身更值得细读的,是 Anthropic 团队在把这套系统从原型跑通到生产可用过程中踩过的坑,他们把这些经验总结成了几条具体的 prompt 工程原则:

• 像 agent 一样思考

为了理解修改提示词会带来什么效果,团队在 Console 里搭建了模拟环境,用系统里完全相同的提示词和工具,逐步观察 agent 如何一步步工作,而不是只看最终输出。

• 精确的任务委派

Lead Agent 必须把查询拆解成边界清晰的子任务,每个子智能体都需要明确的目标、输出格式、工具与信息来源指引、以及任务边界。团队发现,像"研究一下半导体短缺问题"这种模糊指令,会导致子智能体之间重复劳动或偏离主题——曾经出现过一个子智能体在调研 2021 年的汽车芯片危机,另外两个子智能体却在重复调研 2025 年当下的供应链问题这类真实的协调失败案例。

• 让努力程度与任务难度匹配

早期版本的系统会为一个简单问题派生出多达 50 个子智能体,或者无休止地搜索根本不存在的信息来源。团队最终在提示词里嵌入了明确的"effort-scaling"规则:简单的事实查找只需要 1 个子智能体、3-10 次工具调用;直接比较类任务需要 2-4 个子智能体、每个 10-15 次调用;复杂的开放式研究才允许派生 10 个以上的子智能体。

• 给模型一块"草稿纸"

团队让 Lead Researcher 使用扩展思考(extended thinking)作为可控的推理草稿——在真正行动之前,先把"该用哪些工具、该创建几个子智能体"这类计划写出来,再执行。

3.3 OpenAI 的另一条路径:显式移交(Handoff)

与 Anthropic 的"并行扇出"思路不同,OpenAI 在其 Agents SDK 里选择了一套以显式移交(handoff)为核心的编排范式。这套 SDK 是 2025 年 3 月从实验性的 Swarm 项目演进而来的生产级框架,核心抽象是:每个 Agent 由"模型 + 指令 + 工具列表 + 可移交的下游 Agent 列表"定义,一次 handoff 本质上就是一次特殊的工具调用——它会返回另一个 Agent,并让 Runner 把当前的 active agent 切换过去,同时保留完整的共享对话历史。典型的场景是一个 Triage Agent 先判断用户意图,再把控制权顺序移交给账单专员、退款专员等专职 Agent,每一跳都可以插入 Guardrails 做输入输出校验,并且全链路都会被 Tracing 记录下来,便于事后审计每一次模型调用、工具调用与护栏结果。

这套体系里还有一个值得注意的设计取舍:除了 handoff,SDK 同时支持"agent-as-tool"模式——把一个子 Agent 包装成主 Agent 可以调用的工具,而不是彻底转移控制权。OpenAI 官方文档给出的经验法则是:当子任务处于完全不同的业务域时用 handoff(比如客服转接到退款专员),当编排者需要始终掌控全局、只是临时借用某个子 Agent 的能力时用 agent-as-tool——这其实和 Anthropic 的 Lead Agent 保留最终综合权、只把探索性工作下放给 subagent 的思路是同一种工程直觉的两种实现。

Google 的白皮书体系里也呼应了"任务委派"这一思路:在 Vertex AI 的实践中,开发者可以为编排层配置"子智能体"(sub-agents)完成任务委派,只是它更强调依托托管平台(Vertex AI)统一处理部署、评估、调试与性能监控,把更多的工程复杂度交给了云服务本身。

下面这张图把 Anthropic 的并行扇出模式与 OpenAI 的顺序移交模式并排画在一起,便于直观对比两种编排哲学的结构性差异:

图 4：两种主流多智能体编排范式对比——并行扇出追求探索广度，顺序移交追求路径可控与可审计性，二者并非互斥,复杂系统里常常同时存在。

---

4. 长程任务的 Harness:如何跨越多个上下文窗口

---

如果说多智能体架构解决的是"空间"上的扩展(一次性铺开更大的探索面),那么长程 agent harness 解决的是"时间"上的扩展——如何让 agent 在一个上下文窗口装不下的项目里,跨越数小时甚至数天持续、正确地推进。这是 Anthropic 在 2025 年 11 月发布的《Effective harnesses for long-running agents》里给出的核心议题,也是目前公开资料里对"harness"这个词讨论得最直接、最具体的一篇工程博客。

Anthropic 给出的比喻很形象:长程 agent 就像一个轮班倒的工程团队,每个新上任的班次对上一班发生的事情毫无记忆——受限于上下文窗口,复杂项目不可能在一个窗口内做完,agent 必须找到办法在换班之间传递信息。他们观察到,在只给高层提示、缺乏专门 harness 设计的情况下,即便是当时最先进的编码模型,也会反复出现两类失败模式:一是贪多冒进,agent 试图把整个应用一次性"一步到位"地写完,结果在实现过程中就耗尽了上下文,下一个 session 接手一个功能写到一半、且毫无文档说明的烂摊子,只能靠猜测重新摸索,浪费大量时间和 token;二是过早宣布完工,项目进行到中段时,新接手的 agent 实例环顾四周,看到已经有一些功能能跑起来了,就误判"任务已经完成",跳过了尚未实现的部分。

4.1 Initializer Agent + Coding Agent 的两段式结构

Anthropic 给出的解法,是把长程任务拆成两种角色,这与其在 Claude 4 提示词指南中"为第一个上下文窗口使用不同提示词"这一多窗口工作流最佳实践一脉相承:

• Initializer Agent

:只在第一个 session 运行一次,负责搭建环境——写一个能一键启动开发服务器的 init.sh脚本、创建一份把用户原始需求拆解成上百条端到端功能点的 feature_list.json(在 claude.ai 克隆网站这个案例里达到了 200 多条,初始状态全部标记为"未通过"),并提交第一个 git commit,记录初始文件结构。

• Coding Agent

:此后每一个 session 都以此角色运行,被明确要求"一次只推进一个功能",并且在结束前把环境恢复到干净、可合并的状态——通过 git commit 记录变更、更新进度文件,让下一个 session 可以直接复用而不必猜测。

一个容易被忽略但很说明问题的工程细节是:Anthropic 最终选择用JSON 而不是 Markdown来存储功能列表,原因是实验发现模型更不容易"手滑"地误删或覆盖 JSON 文件里的内容;同时他们对 coding agent 使用了措辞强硬的指令——“删除或编辑测试项是不可接受的,因为这可能导致功能缺失或出现 bug 却未被发现”——这说明格式选择本身也是 harness 设计的一部分,不是无关紧要的工程细节。

4.2 让"完成"可验证,而不是靠模型自我感觉

Anthropic 观察到的第三类失败模式是:Claude 倾向于在没有做完整测试的情况下就把某个功能标记为"已完成"。即便没有明确要求,Claude 通常也会做一些代码修改后的验证,比如跑单元测试或者用 curl 命令戳一下开发服务器,但却经常识别不出功能其实端到端并没有真正跑通。解法是显式地要求模型使用浏览器自动化工具(团队接入了 Puppeteer MCP Server),像真实用户一样在浏览器里打开新对话、输入消息、验证收到回复——这类真实的端到端验证工具让 agent 能够发现并修复许多仅从代码层面根本看不出来的 bug。当然这套方法也有已知的局限:Claude 的视觉能力和浏览器自动化工具本身存在盲区,比如无法通过 Puppeteer MCP 看到浏览器原生的 alert 弹窗,依赖这类弹窗的功能因此更容易残留 bug。

为了进一步节省每个 session 摸索环境的 token 开销,团队还要求每个 coding agent 在开工前按固定顺序执行几个基础步骤:先用 pwd 确认自己能操作的目录范围,再读取 git 日志和进度文件了解最近的工作,然后读取功能列表选择优先级最高的未完成项——这种"先摸清现状、再动手"的习惯,本质上是把资深工程师每天上班的第一件事(看看昨天留下了什么)编码进了 harness 的固定流程里。

下面这张图完整还原了这套跨会话交接架构,以及它如何靠文件系统和 git 历史(而不是模型的"记忆")传递工作状态:

图 5：长程 Agent 跨会话交接架构——init.sh、feature_list.json、claude-progress.txt、git 历史共同构成了"外置记忆"，让状态可以在没有模型记忆参与的情况下被完整传递。

为了方便对照阅读,下表把 Anthropic 观察到的四类典型失败模式,和 Initializer / Coding Agent 各自承担的应对动作重新梳理了一遍:

观察到的问题	Initializer Agent 的应对	Coding Agent 的应对
Agent 对整个项目过早宣布完工	依据用户需求建立结构化的功能点列表文件(JSON,初始全部标记 failing)	每个 session 开始时先读取功能列表,只挑一个未完成功能开始做
Agent 把环境搞得有 bug 或进度不可追溯	初始化 git 仓库和进度笔记文件	开局先读进度笔记和 git 提交日志,跑一次基础冒烟测试排查未记录的 bug;结束前写 commit 和进度更新
Agent 过早把功能标记为"已完成"	建立功能点列表文件,作为"完成"的量化标准	使用浏览器自动化等工具做端到端自我验证,只有真正测试通过才标记为 passing
Agent 要反复花时间摸索怎么启动项目	编写可以一键启动开发服务器的 init.sh脚本	session 开始就先读取并运行 init.sh

Anthropic 在文章末尾也坦承了这套方案的局限——目前还不清楚,对于长程任务,究竟是单个通用的编码 agent 表现更好,还是应该进一步拆分成专职的测试 agent、质量保障 agent、代码清理 agent 组成的多智能体架构;这套方法目前也主要在全栈 Web 应用开发场景下得到验证,能否推广到科学研究、金融建模这类长程任务,仍是一个开放问题。这提醒我们,harness 工程目前仍处于一个快速迭代、经验驱动的阶段,还远没有形成像操作系统内核那样稳定的标准范式。

---

5. 安全护栏:自主性不是无限度授权

---

三家公司不约而同地把"人工介入点(human-in-the-loop)"当作 harness 里不可省略的一环,但具体的落地方式各有侧重。

Anthropic 在 Building Effective Agents 中给出的原则相对朴素:在 agent 执行不可逆操作之前——比如批准一笔资金转账、删除数据——设置检查点(checkpoint),让 agent 暂停等待人工审核,而不是全程无人值守地"裸奔"。这套理念也延伸到了 Claude Code 的产品设计里:其"保守的权限模型"常常被误解为一种摩擦,但本质上是一种可编程的安全机制——通过显式的权限声明(比如子智能体只被授予 Read、Grep、Glob、Bash 等特定工具),把"agent 能做什么"这件事从隐式假设变成显式配置。Claude Code 里的 Plan Mode 则是另一种形式的护栏:强制把"探索与规划"和"实际执行"分成两个阶段,避免模型跳过思考直接动手,产出"解决了错误问题"的代码。

OpenAI 的护栏体系则更系统化,体现为 Agents SDK 里的 Guardrails 原语——它在每一轮对话上运行结构化的输入输出校验,专门用来捕获单轮校验容易漏掉的场景,比如跨多轮的提示注入(prompt injection)或者敏感信息泄露(PII leak)。配合 Tracing 能力,每一次模型调用、工具调用、handoff、护栏触发结果都会被完整记录,形成可审计的链路。OpenAI 的实践指南还把"渐进式放权"写成了一条明确的方法论:建议团队从单智能体、小范围试点开始,随着系统在真实用户身上积累的信心增长,再逐步扩大 agent 的自主权限范围——而不是一开始就把所有决策权交给模型。

这三种做法看似形式不同,但背后是同一个工程共识:自主性应该是一个可以被显式调节的旋钮,而不是模型能力提升后自动附赠的默认权限。

---

6. 三家公司方法论对照

---

维度	Anthropic	OpenAI	Google
核心框架	Workflow vs Agent 的架构区分;“tools in a loop”	Model + Tools + Instructions 三要素	Model + Orchestration + Tools 三层
循环机制	多智能体系统中采用 OODA 循环驱动子智能体	Agents SDK 自动管理"调用工具→执行→回传→再调用"的循环,或用 Responses API 自行掌控	推荐 ReAct / CoT / ToT 等推理框架驱动编排层
编排范式	Orchestrator-Worker:Lead Agent 并行扇出多个 Subagent	Handoff(显式移交)+ Agent-as-tool(工具化子智能体)并存	编排层支持配置子智能体做任务委派,依托 Vertex AI 托管
长程任务方案	Initializer Agent + Coding Agent 两段式结构,配合 feature_list.json、progress.txt 与 git 历史	通过 Sessions 原语持久化对话状态,建议从单智能体起步,复杂度提升后再引入多智能体编排	依托 Vertex AI 托管环境统一处理部署、评估与运维复杂度
上下文管理	提出"上下文工程"概念,强调压缩、检索、文件化记忆对抗 context rot	强调工具与指令的清晰度以降低模型决策负担;Sessions 管理跨轮状态	通过 in-context learning、检索增强、微调等多种手段增强模型表现
安全机制	关键操作前设置人工审核检查点;Claude Code 的显式权限声明 + Plan Mode	Guardrails 原语做输入输出校验 + Tracing 全链路审计 + 渐进式放权	依托 Vertex AI 平台内建的评估、调试与性能监控工具链
已知代价/局限	多智能体系统 token 消耗约为单轮对话的 15 倍,不适合强耦合任务	Handoff 链路越长,早期误判越难被后续 Agent 纠正	白皮书更偏概念框架,具体工程细节依赖 Vertex AI 产品文档

---

7. 小结

---

把这些公开资料放在一起看,可以发现一个共识正在形成:agent 的能力天花板由模型决定,但 agent 的可靠性下限由 harness 决定。无论是 Anthropic 用文件系统和 git 记录给长程 agent 搭建"外部记忆",用 orchestrator-worker 模式换取更大的探索广度;还是 OpenAI 把护栏、渐进放权和显式移交写进 Agents SDK 的核心原语;又或是 Google 用编排层统一模型、工具与推理框架的关系、把部署运维复杂度交给 Vertex AI——本质上都是在解决同一个工程问题:如何让一个本身"健忘"、有时"过度自信"、且不具备持久状态的大模型,在真实世界的多步骤任务里表现得像一个靠谱的执行者。

从三家公司近两年的公开材料演进轨迹也能看出一个明显的趋势:2024 年的讨论还停留在"workflow 与 agent 该怎么定义"这种概念层面,2025 年中开始聚焦"多智能体该怎么协调"的架构问题,而到 2025 年末,注意力已经转向"如何让一个 agent 在数小时、数天的时间尺度上保持可靠"这种更贴近生产落地的工程细节。这条轨迹本身,或许就是 harness 工程正在从"研究话题"走向"工程标准"最好的证据。

最后

2026年技术圈的分化愈发明显：降薪裁员潮持续蔓延，传统开发、测试等岗位大批缩水，不少从业者陷入职业焦虑；与之形成鲜明对比的是，AI大模型相关岗位迎来疯狂扩招，薪资逆势飙升150%，大厂更是直接开出70-100W年薪，疯抢具备实战能力的大模型人才，甚至放宽年龄限制，只求能快速落地技术、创造价值！

很多程序员、职场新人纷纷入局大模型领域，绝非盲目跟风，而是实实在在看到了不可替代的价值优势，这也是2026年最值得抓住的职业风口：

1、窗口期红利，入门门槛友好：不同于成熟赛道的“内卷式招聘”，2026年大模型人才缺口巨大，简历只要达标（掌握基础AI应用+具备简单项目经验），年龄、学历均非硬性要求，小白可快速入门，转行程序员也能无缝衔接；

2、技术可复用，上手速度翻倍：如果你有前后端开发、测试、数据分析等基础，在大模型落地、系统部署、Prompt工程等环节会更具优势，无需从零开始，复用原有技术能力就能快速进阶；

3、懂业务更吃香，竞争力翻倍：单纯懂技术已不够，2026年大厂更看重“技术+业务”的复合型人才，有垂直领域（金融、医疗、工业等）经验者，能精准定位模型落地痛点，薪资比纯技术岗高出30%以上；

更重要的是，即便没有转型需求，用AI大模型工具为工作赋能、提升效率，也已经成为80%企业的硬性要求——不会用大模型提效，未来很可能被行业淘汰！

那么2026年，小白/程序员该如何高效学习大模型？

很多人想入门大模型，却陷入两大困境：要么到处搜集零散资料，不成体系，越学越懵；要么被收费高昂的课程割韭菜，花了钱却学不到实战技能，白白浪费时间走弯路。

今天就给大家精心整理了一份2026年最新、免费、系统化的AI大模型学习资源包，覆盖从零基础入门到商业实战、从理论沉淀到面试通关的全流程，所有资料均已整理归档，无需拼凑，直接领取就能上手学习，小白可照做，程序员可进阶！

👇👇扫码免费领取全部内容👇👇

1、大模型系统化学习路线

这份学习路线结合2026年行业趋势和新手学习规律，由行业专家精心设计，从零基础到精通，每一步都有明确指引，帮你节省80%的无效学习时间，少走弯路、高效进阶，避免踩坑。

2、从0到进阶大模型学习视频教程

从入门到进阶这里都有，跟着老师学习事半功倍。

3、大模型学习书籍&电子文档

涵盖2026年最新技术要点，包括基础入门、Transformer核心原理、Prompt工程、RAG实战、模型微调与部署等内容

4、AI大模型最新行业报告

报告包含腾讯、阿里、甲子光年等权威机构发布的核心内容，还有2026年中文大模型基准测评报告、AI Agent行业研究报告等，帮你站在行业前沿，把握技术风口。

5、大模型项目实战&配套源码

项目包含Deepseek R1、GPT项目、MCP项目、RAG实战等热门方向，还有视频配套代码，手把手教你从0到1完成项目开发，既能练手提升技术，又能丰富简历，为求职和职业发展加分。

6、2026大模型大厂面试真题

2026年大模型面试已全面升级，不再单纯考察基础原理，而是转向侧重技术落地和业务结合的综合考察，很多程序员和新手因为缺乏针对性准备，明明技术不错，却在面试中失利。

适用人群

四阶段学习规划（共90天，可落地执行）

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型

• 带你了解全球大模型

• 使用国产大模型服务

• 搭建 OpenAI 代理

• 热身：基于阿里云 PAI 部署 Stable Diffusion

• 在本地计算机运行大模型

• 大模型的私有化部署

• 基于 vLLM 部署大模型

• 案例：如何优雅地在阿里云私有部署开源大模型

• 部署一套开源 LLM 项目

• 内容安全

• 互联网信息服务算法备案

• …

👇👇扫码免费领取全部内容👇👇

7、这些资料真的有用吗？

这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。

资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】