本文深入解析了从Prompt到Graph的大模型工程演进，阐述了五大工程阶段的核心概念与相互关系。从明确指令的Prompt工程，到管理信息的Context工程，再到赋予行动能力的Harness工程，以及实现任务循环的Loop工程，最后到多单元协同的Graph工程，文章揭示了AI工程的核心目标：如何让不确定性模型持续完成任务并交付可验证结果。工程师的角色也从直接推动任务转变为设计自主执行的系统，明确了责任与能力的边界，强调了人在目标设定、规则制定及最终决策中的不可替代性。
Loop Engineering 还没捂热，Graph Engineering 就出现了。又是那个 Vibe Coding 的集大成者 Peter 的新词，没错，就是那个龙虾的创造者。
Graph Engineering，Loop Engineering，Harness Engineering，Context Engineering，Prompt Engineering，感觉快集齐七龙珠了。
可它们不是一代换一代。今天的 Graph 里还跑着 Loop，Loop 得靠 Harness 才动得了，Harness 每次叫模型都要组织 Context，Context 最后还是要变成 Prompt。
这些词到底想表达的是什么意思？纯粹的表达高地？还是方向路标？
从 Prompt 到 Graph，AI 工程其实都是一条主线：
怎样让一个每次输出都带有不确定性的模型，持续做事，并且最终交出可以验证的结果。
模型越来越能干，任务越来越长，工程师需要控制的范围也越来越大。
模型会回答，不等于系统能完成任务
先把大模型单独拿出来看。
你给它一段输入，它根据当前看到的内容，预测接下来该输出什么。模型可以解释问题、写代码、列计划，也可以判断下一步应该调用哪个工具。
但一项真实工作还需要很多模型之外的东西。
它要知道目标和限制，看到项目资料，读取当前状态，操作文件和软件，检查操作是否成功。失败后还要换一种方法，不能说一句“已经完成”就停下来。任务复杂时，它还要等待其他工作、合并多个结果、处理意见冲突。这些能力不会因为模型参数更多，就自动长在系统里。
一个模型知道应该运行测试，不代表它真的能运行测试。
它能运行测试，也不代表它会认真读取失败结果。
它能读取失败结果，也不代表它会继续修改，直到测试通过。
它能把测试全部跑通，也不代表这次改动符合用户真正想要的东西。
所以模型能力和系统能力是两回事。模型负责提出下一步可能做什么，工程系统负责提供信息、工具、状态、反馈和限制，让这些可能性逐渐变成结果。
回头看这几年冒出来的各种 Engineering，变化也就容易理解了。一开始大家只想让模型把话答对，后来开始要求它看懂整个项目、直接动手、连续工作，再到多个 Agent 分工合作。每增加一层能力，都会露出一个更大的缺口。
所以我更愿意把这五个词看成五层逐渐扩大的控制范围：
Prompt 管怎么说，Context 管给模型看什么，Harness 管模型怎么干活，Loop 管任务怎么继续，Graph 管多个执行单元怎么配合。
下面就按这五层，一层一层往外走。
Prompt Engineering：先把任务说清楚
大模型刚进入大众视野时，人们很快发现了一件奇怪的事。
同一个问题，换一种说法，结果可能完全不同。
“帮我写一段代码”和“使用 Kotlin 编写一个线程安全的实现，保留现有接口，并给出异常处理”，得到的东西显然不一样。
于是，大家开始研究怎样给模型下指令：
明确角色，补充背景，规定输出格式，提供示例，把复杂任务拆成步骤，让模型检查自己的答案。
Prompt Engineering 把人平时交代任务的经验写进了提示词。
它背后的判断是：
模型可能已经有这个能力，只是我们没有把任务说对。
这套方法确实有效。任务越明确，限制越具体，模型越不容易跑偏。结构化输入、示例和成功标准，也能明显减少不可用的输出。
但 Prompt 有一道绕不过去的墙：模型没有看到的东西，提示词写得再漂亮也补不回来。
让模型改一个项目却不给它代码，它只能猜。让它分析故障却不给日志，它只能把常见原因列一遍。让它接着昨天的活干，却不告诉它昨天改了什么，它只能从头再来。这时候继续琢磨措辞，是在错误的位置上用力。
Prompt Engineering 解决的是答不对。任务说清楚之后，剩下的问题是它看不全。
Context Engineering：决定模型这一刻该看到什么
Context 不只是用户刚输入的那句话。
模型一次推理时看到的所有内容，都属于 Context：
系统指令、当前任务、历史对话、检索到的文档、代码、工具说明、执行结果、项目规范、工作记录和记忆。
Prompt 只是其中一部分。
所以 Context Engineering 要回答的问题是：这一步该让模型看到什么。它和“能塞进去多少”听着接近，做法几乎相反。
这件事听上去像资料整理，实际比写 Prompt 难得多。模型的上下文窗口有限，就算窗口够长，注意力也不是无限的。
你把整个代码仓库、全部聊天记录、几十份设计文档和所有日志一起扔进去，信息是更多了，答案却未必更好。真正需要的一段错误日志，可能埋在几万行无关内容里。已经过期的设计结论，也可能继续影响后面的判断。
所以 Context Engineering 做的是取舍：什么内容要写进当前 Context，什么内容只放在外部、需要时再读；什么历史应该压缩，什么原始证据必须原样保留；哪些信息该给研究 Agent，哪些信息不该让审核 Agent 提前看到。
长任务之所以经常需要外部文件、任务状态和摘要，就是这个原因。模型不必记住全部过程，但系统必须保证它在下一步拿到够用的信息。
看不全这一关，Context Engineering 能过。
可就算模型看到了项目代码、错误日志和修改要求，它能给你的仍然可能只是一句“建议修改这个文件，然后运行测试”。知道怎么做和真的把事情做完，中间还隔着工具、权限和环境。
Harness Engineering：给模型一套能干活的环境
Harness 很难找到一个完全贴切的中文词。
把它理解成模型外面的执行系统，比较接近实际含义。
它把模型包在里面，给模型准备工具、权限、状态、规则和检查手段。模型不再只是生成一段文字，而是可以读取文件、修改代码、执行命令、访问网页、调用 API，再根据返回结果决定下一步。
一个常见的 Harness 会处理这些事情：
给模型装入当前任务所需的信息；把模型输出转换成工具调用；限制它能访问哪些文件和服务；记录执行过程；在高风险操作前等待人工确认；执行测试和检查；在失败时保存现场。
Prompt 和 Context 仍在里面，只是现在多了行动能力。
做到这一步，工程师的活也跟着变了。他要保证仓库、文档、测试和反馈都能被 Agent 读到、改到，然后把任务描述清楚，剩下的交给 Agent 去改代码、看结果、接受别人的意见再改。
顺带说一句，Harness 和 Loop 的边界没有想象中那么整齐。现实里的 Harness 通常已经包含了部分循环、状态保存和恢复能力。Codex 那套系统就是这样，官方说法里，Harness 指的干脆就是支撑各个 Codex 产品的 Agent 循环和执行逻辑。
所以这五个词适合用来理解关注范围怎么变，不适合当成五个互不相干的软件模块。
到这一层，做不了才算被解决。Harness 把模型从一个会给建议的大脑，变成一个能进真实环境动手的执行者。
模型越强，这层系统反而越重要。
一个只能输出文字的模型答错了，最多浪费一点时间。一个可以删除文件、提交代码、发送邮件或操作生产系统的 Agent 判断错了，后果要大得多。
能力增加之后，系统必须补上更多限制：它能读什么，能改什么，哪些操作必须确认，结果用什么方法检查，出了问题怎样恢复。Harness 的价值不只是给模型更多工具，更重要的是把一部分可靠性从模型身上拿走，交给权限、测试、规则和程序。
但一次运行能够行动，仍不代表它能独立完成一项长任务。很多 Agent 今天的真实用法还是：人发任务，Agent 做一轮；人看结果，指出问题；Agent 再做一轮。中间人不推，任务就停在那儿。
下一步要替代的，正是这个不断催促和检查的人。
Loop Engineering：把“继续做”写进系统
Loop Engineering 不是在 Agent 外面套一个 while true。
要写进系统的是人每一轮都在做的那些判断：看 Agent 做了什么，检查结果，发现不对就补充要求，再决定继续、换方法还是停。
把这套动作变成程序能重复执行的过程，就是 Loop：读取目标和当前状态，调用 Agent 行动，观察环境变化，检查结果，决定下一步。说白了，你不再亲自反复提示 Agent，而是写一个替你提示 Agent 的系统。
一个能稳定跑起来的 Loop，至少要回答几个问题：什么时候启动，当前做到哪一步，这次执行拿到了什么结果，结果由谁检查，失败后重试几次，出现什么情况必须停，什么时候要交给人。
其中最要紧的两个是：根据什么继续，根据什么停止。重复本身反倒是最容易的部分。
最弱的 Loop 会让模型自己判断是否完成。模型写完代码说一句“任务已完成”，循环就结束了。可代码可能没编译，测试没运行，页面根本没打开过。
更可靠的做法是让外部证据来决定：编译是否成功，测试是否通过，页面截图对不对，接口返回是否达到预期，独立审核有没有批准。
Agent 越强，这种检查越不能省。它会多轮行动、调用工具、改动环境，用一问一答的方式去评估它，等于只看了它说的最后一句话。该看的是整个过程和最终状态。
Loop 对付的是做不完。Agent 不必再等人每一轮发话，可以根据结果自己往前推。
但循环也会把前面留下的错误一并放大。目标写错了，它会不停追求错误目标；Context 里混进错误信息，它会反复拿这条信息做决定；Harness 的工具有缺陷，它会一次又一次执行错误操作。停止条件太松，它提前宣布完成；停止条件缺失，它能一直烧时间和 Token。
单个 Loop 还有另一类麻烦。一项复杂任务往往不止一种工作：有人搜资料，有人写代码，有人跑测试，有人查安全。部分工作可以同时做，部分必须等前一步完成，不同的失败还得回到不同位置处理。
把所有事情都塞进一个 Agent 的循环里，Agent 会在越来越长的 Context 中不断切换角色。
这时，需要设计的不再只是一个循环怎样继续，而是多个执行单元怎样分工。
Graph Engineering：开始设计一张执行图
Graph Engineering 把模型调用、Agent、工具、普通程序、检查器和人工确认节点放进同一张图里。
节点负责做事，边决定做完之后去哪里。
一个节点可以是普通函数，也可以是一次模型调用；可以是完整 Agent，也可以是测试程序、权限检查或人工审批。状态在这张图里不断更新，节点读它、改它，边根据它决定下一步走哪。
一个代码任务可以这样组织：需求分析节点先判断任务类型，普通修改交给编码 Agent，涉及安全权限的先进安全检查；编码完成后跑测试，测试失败退回编码 Agent，测试通过交给审核 Agent，高风险改动最后等人工确认。
这张图里可能只有两个 Agent，其余节点全是普通程序。
所以 Graph Engineering 不等于 Multi-Agent，多 Agent 只是它可能采用的形式之一。要紧的是系统明确写出了这几件事：任务怎么拆，状态怎么传，何时分支，何时汇合，失败回到哪里，谁拥有最后的决定权。
Graph Engineering 新的不是图
图、工作流、状态机、DAG 都不是新技术，软件系统早就在用它们处理订单、审批、数据计算和任务调度。LangGraph 用带循环的图搭 Agent Runtime，也是 2024 年的事，比这轮“Graph Engineering”走红早得多。
真正变了的是节点。
传统工作流里的节点大多是确定性程序：输入相同，程序没改，结果通常也相同。某个节点出问题，开发者能查到固定的输入输出，找到对应的那段代码。
Agent 节点不是这样。它会理解目标，生成计划，选择工具，还可能临时创建子任务。同样的输入交给同一个模型，两次执行也可能走出不同的路径。
传统工作流调度的是函数，Agent Graph 调度的是行为。
就这一个变化，会带来一批过去不明显的问题。
一个节点答错，会把错误送到整张图里
研究 Agent 找到一条错误信息，规划 Agent 把它当成前提，编码 Agent 再照着这个前提改代码。节点越多，错误越容易换一种写法继续往下传。
所以节点之间不能只传一句结论，还得交代证据从哪来，哪些是推测，哪些地方压根没查明，当前判断有几分把握。只传结果不传证据，后面的 Agent 很难发现是从哪一步开始走错的。
每个节点都完成任务，整张图仍然可能失败
研究 Agent 的目标是找到更多资料，它可能搜集几十篇文章，把时间和 Token 全部烧完。编码 Agent 的目标是改善代码，它可能做一次大范围重构，把原本两小时的活拖成两天。
每个节点都认真完成了自己的局部任务，不代表整项工作达到了目标。所以 Graph 里必须有人管全局限制：时间、成本、风险、交付范围，以及什么结果才算真正完成。
两个 Agent，不一定真的有两种判断
一个 Agent 叫 Writer，另一个叫 Reviewer，看上去分工已经有了。但它们用的是同一个模型，看到相同的资料，继承同一个错误假设，Reviewer 甚至先读到了 Writer 为自己方案写的那段解释。这种检查很容易变成换一个身份再同意自己一次。
要让审核真的有效，系统得主动制造独立性：审核节点只看原始需求和最终结果，不看作者的解释；换一个模型；调外部测试；高风险的决定直接交给人。
角色名称不会自动带来制衡，信息边界和检查方法才会。
图越动态，越难知道它下一步会做什么
固定工作流容易预测，但不够灵活；完全让模型决定路由，系统能临时改计划，却很难测试和追踪。
实际能用的 Graph 通常两种都要。风险高、规则明确的部分由程序钉死，比如权限检查、金额限制、测试门槛和人工确认；需要理解语义、比较方案的部分再交给模型，比如任务分类、资料选择和失败原因分析。
所以 Graph Engineering 要决定的是：哪些地方可以有弹性，哪些地方必须固定。加多少个 Agent、把多少箭头交给模型，都是这个判断带出来的结果。图的价值也在这里，它把开发者对系统该怎么跑的判断写成了结构本身，在该拦的地方直接拦住模型能走的路。
工程师一直在往外走
把五个阶段放在一起，还能看到另一条变化。
Prompt Engineering 阶段，工程师像个任务交代者，他想的是这句话怎么写，模型才能听懂。
到了 Context Engineering，他开始整理资料：模型这一步需要看到什么，哪些东西会干扰判断。
到了 Harness Engineering，他开始准备工作环境，给模型配工具、权限、规则和检查手段。
到了 Loop Engineering，他要设计任务怎么自己往前走：失败之后怎么办，什么证据可以结束任务，什么时候必须找人。
到了 Graph Engineering，他做的事已经很像组织一支团队：谁先做，谁后做，哪些活并行，谁检查谁，有分歧了听谁的。
工程师没有离场，他只是从亲自推动每一步，转向设计一个能自己跑起来的系统。
过去他告诉模型下一步做什么，现在他要设计的是：
谁负责决定下一步，这个决定又由什么来检查。
绝大多数任务，不需要 Graph
新说法一出现，人们很容易把它当成“更高级的方案”，Graph 也不例外。一个 Agent 不够就放三个；固定流程看着不够聪明，就让模型动态选路；还嫌不够复杂，再加规划 Agent、审核 Agent 和管理 Agent。最后，原本一次模型调用能干完的事，变成十几个节点互相发消息。
Graph 的成本是实实在在的。每加一个节点，就多一种失败方式，多一份状态，多一组输入输出要求，也多一段要追踪的执行过程。节点并行可能同时改同一个文件，两个 Agent 可能给出相反的结论，一个节点超时后面全等着，系统跑出错误结果时，你得沿着整张图去找最早出错的位置。
所以判断顺序应该反过来：先用能完成任务的最简单方案，只在确有需要时才增加 Agent 和工作流的复杂度。写细一点，就是四条：
能用普通程序稳定解决，就不要让模型猜。
能用一次模型调用完成，就不要做 Agent。
能用一个 Agent 完成，就不要同时启动多个 Agent。
能用一个 Loop 表达清楚，就不要急着画复杂的 Graph。
只有当任务确实出现分支、并行、等待、汇合、独立检查和不同恢复路径时，Graph 才开始值回它带来的成本。
能力可以交出去，责任不会
工业革命把人的体力交给了机器。蒸汽机不理解工厂为什么要生产一件商品，但它能持续输出远超人力的力量。机器一多，限制工厂的就不再是单台机器的性能，而是原料怎么进、工序怎么排、产品怎么检、故障怎么处理。工程师于是不再只设计一台机器，开始设计生产线和工厂。
这一次交出去的东西不一样，是判断：读哪些资料，用什么工具，下一步做什么，失败了怎么调整，什么时候可以认为事情已经做完。Prompt 到 Graph 这五个词，记录的就是这些判断被一层层写进系统的过程。
但能力可以交出去，责任不会跟着一起走。
工厂出了事故，不能说是机器自己选择了运转
最后
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 学习资料已经上传优快云，朋友们如果需要可以微信扫描下方优快云官方认证二维码免费领取【保证100%免费】
5649
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
