AI 应用工程篇: 五个工程的前置认知铺垫

Prompt → Context → Harness → Loop → GraphAI 应用的工程重心正在从“怎么问模型”逐渐转向“怎么构建让模型稳定工作的系统”。Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering一、开篇今天我想分享一个今年在 AI Agent 领域比较有意思的话题。这几个词大家可能都听过Prompt EngineeringContext EngineeringHarness EngineeringLoop EngineeringGraph Engineering如果单独看每一个词似乎都不难理解。Prompt Engineering提示词工程。Context Engineering上下文工程。Harness EngineeringHarness 工程。Loop Engineering循环工程。Graph Engineering图工程。但是把这五个词放在一起就会发现它们其实描述的是一个非常有意思的变化AI 应用开发的工程重心正在不断向更高层次移动。最开始我们研究的是怎么把 Prompt 写好后来发现Prompt 写得再好如果模型没有足够的信息也没有用。于是开始研究模型这一轮到底应该看到什么再后来模型已经不只是回答问题而是开始调用工具、修改文件、执行代码、访问数据库。这时候问题又变成怎么给模型提供一个可靠的运行环境再往后如果 Agent 要自己运行几十轮、几百轮什么时候运行什么时候继续什么时候重试什么时候停止最后当一个 Agent 已经不够我们需要多个 Agent、工具、验证器、人工节点协同这些节点应该怎么连接于是就形成了今天这五个关键词Prompt ↓ Context ↓ Harness ↓ Loop ↓ Graph今天我们就按照这个顺序来理解。二、Prompt Engineering我应该怎么告诉模型先从最熟悉的 Prompt Engineering 开始。Prompt Engineering本质上是在研究如何设计给模型的指令让模型产生更加符合预期的输出。比如我们直接告诉模型帮我写一个登录接口。模型当然可以写。但是如果我们把要求写得更加明确你是一名 Java 后端工程师。 请使用 Spring Boot 3 MyBatis Plus 实现用户登录接口。 要求 1. 使用 RESTful API 2. 密码使用 BCrypt 加密 3. 登录成功返回 JWT 4. 参数使用 Bean Validation 校验 5. 统一使用 ResultT 返回 6. 给出 Controller、Service、Mapper 和 DTO通常得到的结果会更加稳定。这就是 Prompt Engineering。它关注的是Instruction Role Constraint Example Output Format也就是我要怎么说模型才能更好地理解我的意图Prompt Engineering 的局限但是问题很快就出现了。假设我告诉 AI帮我修复这个项目中的登录 Bug。Prompt 写得再漂亮如果 AI 根本不知道项目的目录结构数据库表结构登录流程Redis 配置JWT 生成方式项目的编码规范之前已经尝试过什么测试怎么运行它还是很难真正解决问题。所以我们发现模型的问题有时候不是“不知道怎么做”而是“根本不知道相关信息”。这时候工程重心就开始从 Prompt 转向 Context。三、Context Engineering这一轮到底应该让模型看到什么Anthropic 对 Context Engineering 的一个核心描述是Prompt Engineering 关注如何编写指令而 Context Engineering 更关注如何在模型推理时动态组织和维护它所需要的信息。([Anthropic][1])简单来说Prompt 是“我告诉你什么”Context 是“你现在知道什么”。例如我们开发一个 AI 客服。用户说我上次买的那双鞋什么时候发货如果只看 Prompt你是一个电商客服请帮助用户解决问题。模型根本不知道用户是谁 买了什么 订单号是什么 物流状态是什么所以系统需要动态构建 ContextSystem Prompt 用户信息 历史对话 订单信息 物流信息 商品信息 相关知识库 ↓ 最终 Context ↓ LLM这就是 Context Engineering。Context Engineering 到底在工程什么可以把它拆成几个问题。1. Retrieve拿什么从数据库、RAG、API、搜索引擎中找到相关信息。2. Select选什么不是所有信息都应该塞进去。3. Compress压缩什么历史对话越来越长需要摘要、压缩。4. Structure怎么组织同样的信息不同的结构可能产生不同的效果。例如用户 张三 订单 订单号10086 商品Nike Air Max 状态运输中比把所有信息直接拼成一大段文本更加容易被模型正确使用。5. Isolate隔离什么不同 Agent、不同任务不应该看到全部上下文。所以 Context Engineering 本质上是在解决有限 Context Window 下如何让模型在当前时刻获得最有价值的信息。四、Harness Engineering不仅给模型信息还要给它一个“工作环境”当 AI 从 Chatbot 变成 Agent问题又发生变化。以前User ↓ Prompt ↓ LLM ↓ Answer现在User ↓ Agent ↓ LLM ↓ Tool ↓ Environment ↓ Observation ↓ LLM ↓ Tool ↓ ...比如 Coding Agent。它可能需要读取文件 修改代码 执行 Shell 运行测试 查看 Git Diff 搜索代码 访问数据库这时候单纯 Prompt 和 Context 已经不够。我们需要一个Harness可以把 Harness 理解成围绕模型构建的一整套运行环境和控制机制。它决定模型能看到什么 模型能调用什么 模型能修改什么 模型不能做什么 怎么验证结果 失败之后怎么办 什么时候认为任务完成Anthropic 对 Agent 的 Context 管理强调了工具、MCP、历史、外部数据等动态状态而 Harness Engineering 则进一步进入运行环境、权限、工具、验证和反馈等系统层面。([Anthropic][1])一个 Coding Agent 的 Harness例如┌───────────────┐ │ LLM │ └───────┬───────┘ │ ┌───────────────┼───────────────┐ ↓ ↓ ↓ 文件系统 Terminal Git ↓ ↓ ↓ Read/Write Execute Diff │ │ │ └───────────────┼───────────────┘ ↓ Tests ↓ Verification这里File System 是工具Terminal 是工具Git 是工具Test 是验证机制Permission 是约束Sandbox 是运行环境Context Manager 是上下文管理这些东西共同构成了 Agent 的 Harness。所以可以记住一句话Model 提供智能Harness 提供可执行、可控制、可验证的工作环境。五、Loop Engineering如果 Agent 不只运行一次呢现在我们已经有Prompt Context HarnessAgent 可以开始干活了。但真实任务往往不是执行一次 → 完成而是执行 ↓ 观察结果 ↓ 发现错误 ↓ 修改 ↓ 再次执行 ↓ 测试 ↓ 继续修改 ↓ 再次测试 ↓ 完成这就是 Loop。Loop Engineering 关注的是如何设计 Agent 的持续运行循环。IBM 在 2026 年对 Loop Engineering 的定义就是设计能够反复引导 Agent 朝目标前进、减少人工干预的 Agentic Workflow。([IBM][2])一个最简单的 Agent Loop┌──────────────┐ │ Goal │ └──────┬───────┘ ↓ ┌──────────────┐ │ Think │ └──────┬───────┘ ↓ ┌──────────────┐ │ Act │ └──────┬───────┘ ↓ ┌──────────────┐ │ Observe │ └──────┬───────┘ ↓ ┌──────────────┐ │ Verify │ └──────┬───────┘ ↓ Done? / \ No Yes ↓ ↓ Retry Stop │ └──────────→这里最重要的其实不是“循环”。而是三个东西1. Goal到底什么叫完成比如让所有测试通过比把代码优化得更好更加适合作为 Agent Goal。2. Verification不能让 Agent 自己说我觉得已经完成了。而应该mvn test npm test pytest typecheck lint用确定性的工具验证。3. Stop Condition必须告诉 Agent什么时候停止例如测试全部通过或者连续 3 次失败或者达到 Token / Cost Budget或者需要人工审批Loop Engineering 的核心就是把“我再给 AI 发一句 Prompt”变成“我设计一个可以自己运行、验证、重试、停止的系统。”这也是 2026 年 Loop Engineering 这个术语快速出现的核心背景。([Loop Engineering][3])六、Graph Engineering一个 Loop 不够了怎么办到这里我们有一个 Agent Loop。但是复杂任务可能是需求分析 ↓ 代码实现 ↓ 测试 ↓ Code Review ↓ 安全检查 ↓ 部署而且其中还可能出现测试失败 ↓ 返回开发 Agent 安全检查失败 ↓ 返回安全 Agent 高风险操作 ↓ 人工审批这已经不是简单的 Loop。它更像一个Graph。Graph Engineering 就是在关注如何把多个 Agent、工具、任务、验证器、人工节点组织成一个可观察、可控制、可恢复的任务图。不过这里必须强调Graph Engineering 目前仍然是一个正在形成中的架构标签并不是像 HTTP、TCP 这样的标准化技术名词。不同资料对它的边界也存在差异。([GitHub][4])所以分享的时候不要把它说成“行业已经统一定义的标准”。一个 Agent Graph例如一个 AI 软件开发系统┌──────────────┐ │ Requirement │ └──────┬───────┘ ↓ ┌──────────────┐ │ Planner │ └──────┬───────┘ ↓ ┌──────────────┐ │ Developer │ └──────┬───────┘ ↓ ┌──────────────┐ │ Test │ └──────┬───────┘ Pass│Fail ┌────┴────┐ ↓ ↓ Review Developer ↓ Security ↓ Human Approval ↓ Deploy这时候每一个节点都可能拥有自己的Prompt Context Tools Harness Loop而 Graph 负责节点之间怎么连接 什么时候进入下一个节点 什么时候回退 什么时候分支 什么时候并行 什么时候需要人工介入所以可以把它理解成Loop 解决“一个 Agent 怎么持续工作”Graph 解决“多个工作节点怎么协同”。七、五个概念到底是什么关系现在把五个概念放在一起。Engineering核心问题关注对象Prompt Engineering我应该怎么告诉模型指令Context Engineering模型这一刻应该知道什么信息Harness Engineering模型应该在什么环境里工作工具、权限、验证、运行环境Loop Engineering模型应该如何持续工作循环、状态、重试、停止Graph Engineering多个 Agent / 工具如何协同工作流、节点、边、分支可以用一句话记忆Prompt 怎么说 Context 给什么信息 Harness 给什么工作环境 Loop 怎么持续干 Graph 多个角色怎么协同八、为什么会出现这种演进我认为核心原因只有一个模型能力越来越强之后瓶颈开始从“模型本身”转移到“模型周围的工程系统”。以前模型能力不够。所以大家最关心换哪个模型 模型参数多少 Prompt 怎么写但是当模型已经能够写代码 调用工具 搜索信息 修改文件 运行测试 自主规划问题就变成它看到了什么 它能做什么 它做错了怎么办 它怎么知道自己做错了 它什么时候应该停止 多个 Agent 怎么协同所以工程关注点开始向外扩展。九、用一个“AI 程序员”把五个概念串起来假设我要做一个 AI Coding Agent。用户输入帮我给项目增加一个 Redis 缓存。第一步Prompt Engineering告诉模型你是一名 Java 后端工程师。 请为项目增加 Redis Cache。 遵循现有项目代码规范。解决怎么说第二步Context Engineering系统自动给模型项目目录 Spring Boot 版本 pom.xml 相关 Service 现有 Redis 配置 数据库结构 代码规范 历史修改记录解决模型需要知道什么第三步Harness Engineering给模型Read File Write File Search Terminal Git Maven Test同时限制不能访问生产数据库 不能直接 push main 不能删除项目解决模型在哪里工作能做什么不能做什么第四步Loop EngineeringAgent 开始分析 ↓ 修改代码 ↓ mvn test ↓ 失败 ↓ 读取错误 ↓ 修改 ↓ mvn test ↓ 通过 ↓ 停止解决模型怎么持续完成任务第五步Graph Engineering进一步拆成Planner ↓ Developer ↓ Tester ↓ Reviewer ↓ Security ↓ Human ↓ Deploy解决复杂任务如何组织多个 Agent 和工具十、最后总结所以今天的五个关键词我认为可以浓缩成一个非常简单的模型AI Engineering │ ┌──────────────┴──────────────┐ ↓ ↓ 单次交互 Agent System │ │ Prompt Context │ Harness │ Loop │ Graph或者更简单Prompt → Context → Harness → Loop → Graph 怎么说 知道什么 怎么工作 怎么持续 怎么协同这五个词真正有价值的地方并不是让我们多记五个 AI 黑话。而是它们帮助我们理解一个变化AI 应用开发正在从“Prompt 开发”逐渐走向“Agent 系统工程”。当我们还在研究“这个 Prompt 怎么改得更好”的时候也许下一步真正应该问的是“模型现在缺什么 Context” “它有哪些 Tool” “它的 Harness 怎么设计” “它怎么验证” “什么时候停止” “多个 Agent 怎么协同”这可能才是未来 AI 应用工程真正有技术含量的地方。谢谢大家。2. 博客.md从 Prompt Engineering 到 Graph EngineeringAI Agent 工程范式的五次跃迁Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering → Graph Engineering最近 AI Agent 领域出现了一组越来越频繁的工程术语Prompt EngineeringContext EngineeringHarness EngineeringLoop EngineeringGraph Engineering乍一看它们像是一堆新的 AI 黑话。但如果把它们放在一起观察会发现这五个概念其实描述了一条非常清晰的演进路径AI 应用开发的工程重心正在从“如何告诉模型”逐渐转向“如何构建一个让模型稳定完成任务的系统”。需要提前说明的是Prompt Engineering、Context Engineering、Harness Engineering 已经形成了较清晰的工程语义Loop Engineering 和 Graph Engineering 则是 2026 年快速兴起的术语目前不同实践者对边界仍有不同理解。因此本文把后两者作为一种理解 Agent 系统架构的工程视角而不是严格的行业标准。([Anthropic][1])一、五个概念先看懂如果只想记住最核心的东西可以直接记下面这张表。概念核心问题关注对象Prompt Engineering我应该怎么告诉模型InstructionContext Engineering模型这一刻应该知道什么ContextHarness Engineering模型应该在什么环境里工作Runtime / Tools / GuardrailsLoop Engineering模型应该如何持续完成任务Loop / State / VerificationGraph Engineering多个 Agent 如何协同Graph / Workflow一句话概括Prompt 怎么说 Context 给什么信息 Harness 给什么工作环境 Loop 怎么持续干 Graph 怎么组织多个角色协同接下来逐层展开。二、Prompt Engineering怎么告诉模型2.1 什么是 Prompt EngineeringPrompt Engineering也就是提示词工程。它研究的是如何设计给 LLM 的指令使模型更稳定地产生预期结果。例如帮我写一个 Spring Boot 登录接口。这属于非常简单的 Prompt。进一步增加约束你是一名 Java 后端工程师。 使用 Spring Boot 3 MyBatis Plus 实现用户登录。 要求 1. 使用 RESTful API 2. 使用 Bean Validation 校验参数 3. 密码使用 BCrypt 4. 登录成功返回 JWT 5. 使用统一 ResultT 返回 6. 给出 Controller、Service、Mapper、DTO模型得到的任务边界明显更加清晰。Prompt Engineering 主要关注Role Instruction Constraint Example Output Format也就是如何把人的意图转换成模型更容易执行的指令。三、Prompt Engineering 为什么不够假设现在任务变成帮我修复这个项目的登录 Bug。即使 Prompt 写得非常漂亮模型还是可能不知道项目使用什么框架 登录代码在哪里 数据库表是什么 Redis 怎么配置 JWT 怎么生成 之前修改过什么 项目应该如何测试这就出现了一个非常关键的问题模型不是不知道怎么做而是不知道足够的信息。因此工程问题从怎么写 Prompt逐渐转变为这一轮到底应该把什么信息给模型这就是 Context Engineering。四、Context Engineering模型应该知道什么Anthropic 将 Context Engineering 描述为不仅设计 Prompt而是管理模型推理时所获得的完整上下文包括系统指令、工具、MCP、外部数据、消息历史等。([Anthropic][1])因此可以简单理解Prompt 是你对模型说的话Context 是模型在当前时刻所拥有的工作信息。4.1 一个 AI 客服的例子用户我上次买的鞋什么时候发货System Prompt你是一名电商客服。显然不够。系统可能需要动态获取用户信息 订单信息 商品信息 物流信息 历史对话 售后政策最终┌──────────────┐ │ System Prompt│ └──────┬───────┘ │ 用户 ───────→ Context Builder │ ┌────────────┼────────────┐ ↓ ↓ ↓ Order DB RAG History │ │ │ └────────────┼────────────┘ ↓ Final Context ↓ LLM这就是 Context Engineering。4.2 Context Engineering 的几个核心动作Retrieve从数据库、RAG、API、搜索引擎中找到相关信息。Select不是检索出来的所有内容都需要给模型。Compress历史越来越长需要摘要、压缩。Structure把信息组织成模型容易理解的结构。Isolate不同任务、不同 Agent 不一定需要看到全部信息。因此 Context Engineering 真正解决的是有限 Context Window 下如何让模型在当前时刻获得最有价值的信息。Google Cloud 也将 Context Engineering 描述为从简单 Prompt 转向构建结构化数据和信息环境的过程。([Google Cloud][5])五、Harness Engineering模型开始“干活”了如果说Prompt 告诉模型做什么 Context 告诉模型它需要知道什么那么 Harness Engineering 关注的是给模型什么样的运行环境让它真正能够完成任务。这是从 Chatbot 走向 Agent 的关键一步。六、从 Chatbot 到 Agent传统 ChatbotUser ↓ Prompt ↓ LLM ↓ AnswerAgentUser ↓ Agent ↓ LLM ↓ Tool ↓ Environment ↓ Observation ↓ LLM ↓ Tool ↓ ...比如一个 Coding Agent 可能需要File System Terminal Git Search Database Browser Test Runner模型本身并不会天然拥有这些能力。我们需要在模型周围搭建一层系统。这就是 Harness。七、Harness 到底包含什么可以粗略理解成┌─────────────┐ │ LLM │ └──────┬──────┘ │ ┌────────────────┼────────────────┐ ↓ ↓ ↓ Tools Context State ↓ ↓ ↓ File / Git Memory / RAG Task State │ ↓ Environment │ ↓ Verification │ ↓ Guardrails典型组件包括Tool CallingFile SystemTerminalSandboxPermissionsMemoryContext ManagementVerificationObservabilityGuardrails2026 年关于 AI Harness Engineering 的研究也开始把任务规格、上下文选择、工具访问、状态、可观测性、验证、权限等视为 Harness 的重要职责。([arXiv][6])因此Model 提供智能Harness 提供运行环境。八、Loop Engineering让 Agent 自己不断推进有了 HarnessAgent 可以执行任务。但是一个复杂任务通常不是执行一次 ↓ 完成而是Plan ↓ Act ↓ Observe ↓ Verify ↓ Retry ↓ Observe ↓ Verify ↓ Done这就是 Loop。IBM 对 Loop Engineering 的定义就是设计能够反复引导 Agent 朝目标推进、减少人工逐步干预的 Agentic Workflow。([IBM][2])九、一个最基本的 Agent Loop┌───────────┐ │ Goal │ └─────┬─────┘ ↓ ┌───────────┐ │ Think │ └─────┬─────┘ ↓ ┌───────────┐ │ Act │ └─────┬─────┘ ↓ ┌───────────┐ │ Observe │ └─────┬─────┘ ↓ ┌───────────┐ │ Verify │ └─────┬─────┘ ↓ Done? / \ No Yes ↓ ↓ Retry Stop │ └───────────→这里真正重要的不是“循环”两个字而是Goal必须明确什么叫完成。例如让全部测试通过比优化代码更适合作为 Agent 的目标。Verification不要让 Agent 自己判断应该已经好了。而应该mvntestpytestnpmtestnpmrun typecheck用确定性工具验证。Stop Condition必须明确什么时候停止例如测试全部通过 连续 3 次失败 超过 Token Budget 超过时间限制 触发高风险操作 需要人工审批因此 Loop Engineering 的核心思想可以概括成不要不断手动给 Agent 发下一条 Prompt而是设计一个能够自己推进、验证、重试和停止的循环。十、Harness 和 Loop 有什么区别这是非常容易混淆的地方。可以这样理解Harness 一个 Agent 怎么工作 Loop 这个 Agent 怎么持续工作例如Harness LLM Tools Context Permissions Sandbox Verification而 Loopwhile (!done) { context buildContext(); result agent.run(context); verify(result); if (success) { break; } retry(); }所以Harness 是运行环境Loop 是控制循环。十一、Graph Engineering一个 Agent 不够了再往上走。假设我们要让 AI 自动完成一个软件开发任务需求分析 ↓ 代码实现 ↓ 测试 ↓ Code Review ↓ 安全检查 ↓ 部署显然一个 Agent 全包并不是唯一方案。我们可以把任务拆成多个节点Requirement ↓ Planner ↓ Developer ↓ Test / \ Pass Fail ↓ ↓ Review Developer ↓ Security ↓ Human Approval ↓ Deploy这就是 Graph。十二、什么是 Graph EngineeringGraph Engineering 可以理解为设计多个 Agent、工具、验证节点、人工节点之间的关系以及它们之间的信息和控制流。它解决的问题已经从一个 Agent 怎么工作升级到了多个 Agent 怎么协同工作需要设计NodeEdgeBranchParallelStateCheckpointHuman GateRetryFailure Route例如Planner │ ├────→ Developer │ │ │ ↓ │ Tester │ / \ │ Pass Fail │ │ │ │ ↓ └──→ Developer │ Reviewer │ │ │ ↓ │ Security │ │ │ ↓ └──→ Human需要强调的是Graph Engineering 目前仍是一个正在形成中的工程术语不同资料对它的定义并不完全一致。一些实践将它理解为多 Agent / 工具 / 检查点的显式工作图也有实践将它进一步扩展到任务图、信息流和状态拓扑。([GitHub][4])因此更适合把它理解成一种Agent 系统的架构设计视角。而不是一个已经标准化的技术规范。十三、五个 Engineering 到底是什么关系现在重新看这五个概念Prompt Engineering ↓ Context Engineering ↓ Harness Engineering ↓ Loop Engineering ↓ Graph Engineering它们实际上是在不断扩大“工程对象”。第一层Prompt工程对象一句 Prompt问题怎么说第二层Context工程对象模型当前看到的信息问题模型应该知道什么第三层Harness工程对象模型周围的运行环境问题模型能做什么 在哪里做 怎么约束 怎么验证第四层Loop工程对象Agent 的持续执行过程问题怎么继续 怎么重试 怎么验证 什么时候停止第五层Graph工程对象多个 Agent / Tool / Human Node 的协作关系问题复杂任务怎么拆 节点怎么连接 什么时候分支 什么时候回退 什么时候人工介入十四、用 AI Coding Agent 串起来假设我要做一个 AI 程序员。用户输入帮我给这个 Spring Boot 项目增加 Redis 缓存。Prompt Engineering设计你是一名 Java 后端工程师。 请给当前项目增加 Redis Cache。 遵循现有代码规范。解决怎么告诉模型Context Engineering自动提供项目结构 pom.xml Spring Boot Version Service Controller Redis Config 数据库结构 相关代码 历史修改记录解决模型应该知道什么Harness Engineering给模型Read Write Search Terminal Git Maven Test同时限制禁止访问生产数据库 禁止删除项目 禁止直接 push main解决模型在哪里工作能够做什么Loop EngineeringAgent分析代码 ↓ 修改代码 ↓ mvn test ↓ 失败 ↓ 读取错误 ↓ 修复 ↓ mvn test ↓ 通过 ↓ 结束解决模型如何持续完成任务Graph Engineering进一步拆分Planner ↓ Developer ↓ Tester ↓ Reviewer ↓ Security ↓ Human ↓ Deploy解决多个 Agent 和工具如何协同十五、为什么这些概念现在突然流行本质上是因为LLM 的能力越来越强系统的瓶颈开始从模型本身向模型周围的工程基础设施转移。早期我们经常讨论哪个模型更强 GPT 还是 Claude Prompt 怎么写但当模型已经可以写代码 搜索资料 调用 API 操作文件 运行程序 修改代码 运行测试真正的问题开始变成它应该看到什么 它能调用哪些工具 它拥有哪些权限 它怎么知道自己错了 失败以后怎么恢复 怎么防止无限循环 怎么控制成本 多个 Agent 怎么协作 什么时候必须人工介入这也是为什么 Context Engineering 被 Anthropic 描述为 Prompt Engineering 在 Agent 时代的自然延伸而 Harness Engineering、Loop Engineering 等概念进一步把问题扩大到运行环境和持续执行机制。([Anthropic][1])十六、最终总结可以用一张图记住这五个概念┌─────────────────────────────────────────────┐ │ Graph Engineering │ │ 多 Agent / Tool / Human 如何协同 │ │ │ │ ┌─────────────────────────────────────┐ │ │ │ Loop Engineering │ │ │ │ Agent 如何持续执行与验证 │ │ │ │ │ │ │ │ ┌─────────────────────────────┐ │ │ │ │ │ Harness Engineering │ │ │ │ │ │ Agent 在什么环境工作 │ │ │ │ │ │ │ │ │ │ │ │ ┌─────────────────────┐ │ │ │ │ │ │ │ Context Engineering │ │ │ │ │ │ │ │ 模型应该知道什么 │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ Prompt Engineering │ │ │ │ │ │ │ │ 我应该怎么告诉模型 │ │ │ │ │ │ │ └─────────────────────┘ │ │ │ │ │ └─────────────────────────────┘ │ │ │ └─────────────────────────────────────┘ │ └─────────────────────────────────────────────┘也可以直接记成Prompt ↓ 怎么说 Context ↓ 知道什么 Harness ↓ 怎么工作 Loop ↓ 怎么持续 Graph ↓ 怎么协同这五个概念真正值得关注的地方并不是多了五个 AI 名词。而是它们体现了一个非常明显的趋势AI Engineering 正在从 Prompt Engineering 逐渐走向 Agent System Engineering。过去我们把模型当成一个“回答问题的函数”。现在越来越多的系统开始把模型当成一个Reasoning Engine Tools Context Memory Runtime Verification Loop Workflow最终形成真正能够完成工作的 Agent System。所以当你下一次开发 AI 应用时与其只问“我的 Prompt 写得够好吗”不如继续问模型现在缺什么 Context 它拥有哪些 Tools Harness 怎么设计 结果如何 Verification Loop 如何 Retry 什么时候 Stop 多个 Agent 如何 Graph 化这可能才是从“会调用大模型”走向“真正做 AI 应用工程”的关键一步。