过去几年，AI 圈不断出现新的 Engineering：Prompt、Context、Harness、Loop，最近 Graph Engineering 也开始被频繁讨论。可以把今天的 Agent 工程理解为多个相互嵌套、但边界并不绝对的关注层次。随着模型能力提升，工程重心也逐渐从单次调用扩展到运行环境、持续执行与多 Agent 协作。下面我们用 Qoder CLI 和 Qoder Cloud Agents 举例，看清 Context、Harness、Loop 与 Graph 各自解决什么问题。
本质从没变，变化的是工程瓶颈
多数 tool-using Agent 都可以抽象成一个循环：模型读取当前上下文，推理并决定下一步，调用工具执行，再把结果写回上下文，直到本次任务完成、失败或被外部打断。真实产品会更复杂，但这个简化模型足以解释这些概念。
早期模型指令跟随能力弱，Prompt 的措辞稍有变化，结果就可能明显不同，于是 Prompt Engineering 成为焦点。后来模型能够理解更复杂的指令，瓶颈转向上下文：该给什么信息、何时给、如何压缩。当模型开始连续调用工具，工程关注点又扩展到承载一次 Agent 运行的 Harness。再往外，如何围绕目标反复触发、验证并持续执行，成为 Loop Engineering 关心的问题；当多个 Agent 或 Loop 需要分工协作，Graph 又被推到台前。
每一种 Engineering，都在解决当前最突出的系统瓶颈。随着模型能力提升，旧问题不会消失，而会被模型吸收、被框架固化，或被平台做成默认能力。
下面具体看看，它们在本地 CLI 和云端 Agent 平台中分别长什么样。
Context Engineering：管理上下文，就是管理注意力
以 Qoder CLI 为例，任务开始时不会把所有资料一股脑塞进上下文。系统先加载必要的项目指令，以及可用 Skill 的名称和简介；只有任务命中某个 Skill 时，才完整读取，这也就是渐进式披露（progressive disclosure）。
AGENTS.md 的作用域机制也是同一思路：全局层保存个人偏好，项目层保存仓库约定，更具体的规则只在对应目录生效。Subagent 则提供上下文隔离，让代码探索、文件阅读和试错过程留在子上下文中，主上下文只接收必要证据和结论。
因此，Context Engineering 的重点不是“塞得更多”，而是管理有限的注意力预算：什么应该常驻，什么按需加载，什么需要压缩，什么应该丢弃。到了云端，Qoder Cloud Agents 用持久化 Session 保存可继续的工作状态和事件历史，调用方不必在每次请求中重新拼装全部运行上下文。
Harness Engineering：构建模型的执行环境
同一个模型，直接调用 API 和放进成熟的 Qoder CLI，表现可能相差很大。通常把模型之外、但直接影响执行质量的环境称为 Harness，包括上下文组装、工具、权限、文件系统、沙箱、状态反馈、测试和可观测性。
Qoder CLI 本身就是一个 Harness。Plan Mode 约束会话处于分析和规划状态，Permission Mode 决定权限检查的松紧——工具调用是自动放行、询问确认还是直接拒绝；受信目录和工具白名单限制能力边界，settings 与 Hooks 则注入项目约束和确定性检查。安全不只靠 Prompt，还依赖运行时权限和可执行规则。
云端 Harness 还要处理本地单用户环境没有的多租户问题。在 Qoder Cloud Agents 的核心运行时里，Agent 定义能力，Environment 提供运行环境，Session 承载一次具体任务；面向业务交付的 Forward Mode 构建在这之上，用 Template 定义可复用的配置基线，用 Identity 区分终端用户，为每个用户合成各自的运行配置。每个 Session 都运行在隔离的 Sandbox 中，Vault 负责安全注入凭证。无论在本地还是云端，Harness Engineering 解决的都是同一个问题：怎样让模型在边界清楚、反馈及时的环境里稳定工作。
Loop Engineering：让系统持续运行到目标达成
Loop Engineering 关注的是一次 Agent 运行之外的闭环：谁触发下一轮，完成条件是什么，结果由谁验证，失败后应该重试、恢复还是交给人，以及状态如何跨会话多次运行延续。
在本地 CLI 中，人通常仍是外层循环的一部分：提出目标、观察进展、检查结果，再决定继续、修改还是停止。当目标、验证、重试和停止条件被固化成可重复执行的机制，系统就开始从“人不断提示 Agent”转向“人设计一个能够持续推进的循环”。
到了云端，这个外层循环不再依赖有人盯着终端。Qoder Cloud Agents 用持久化 Session 保存状态，用 Event 和 SSE 暴露执行过程，并允许外部系统取消当前 Turn 或继续下一轮。Schedule 和 IM Channel 负责按时间或外部消息触发，Batch 则让同一类任务批量运行。控制者可以是业务系统、监控规则或审批流程，Loop Engineering 关心的正是怎样让这些运行持续推进，又能在正确的条件下停下来。
Graph Engineering：连接多个 Agent 或 Loop
Graph Engineering 的基础仍然是 state、nodes 和 edges。节点可以是一段确定性代码、一次模型调用，也可以是一段完整的 Agent 运行；边决定任务如何流转，state 则承载节点之间需要共享的信息。
主会话把不同模块交给多个 Subagent 排查，就可以抽象为：Subagent 是节点，委派与结果反馈是边，任务说明、证据和结论是流动的 state。Loop 决定一个运行过程如何返回、验证和继续，Graph 则进一步决定多个执行单元之间的依赖、路由和协作关系。一个 Loop 可以看成最简单的循环图，一张 Graph 里也可以包含多个 Loop。
Qoder CLI 中的 Graph 通常在一次会话里动态形成，适合开发、调试和探索。Qoder Cloud Agents 则原生支持 Coordinator Agent 向多个 Child Agent 并行或串行委派任务，形成运行时的动态协作图；对于包含固定依赖、条件路由和跨 Session 状态的显式 Graph，上层系统还可以基于 Agent、Session、Thread 与 Event API 进一步编排。此时需要处理的不只是单个 Agent 能否完成任务，还包括节点之间的状态传递、权限边界、失败恢复和整体可观测性。
四种 Engineering，一套 Agent 系统
回到最初的 Agent 系统，四个概念回答了不同层次的问题：Context 决定一次模型调用看见什么，Harness 决定一次 Agent 在什么环境中运行，Loop 决定多次运行如何持续推进到目标，Graph 决定多个 Agent 或 Loop 如何连接。
它们不是四套彼此替代的方法，而是同一套 Agent 系统由内向外的四个工程层次。模型能力还会继续变化，新的 Engineering 也会不断出现；需要关注的，始终是系统当前最需要工程化解决的那一层。
把 Agent 托管到云端
文中的四个层次，Qoder Cloud Agents 都做成了平台默认能力。核心运行时里，Agent 与 Session 负责定义和运行，Sandbox 与 Vault 划定边界，Event 与 SSE 暴露过程，Managed Agents 提供原生的多 Agent 委派；面向业务交付的 Forward Mode 再往上一层，用 Template 与 Identity 管理多租户配置，用 Schedule、Batch 和 IM Channel 决定执行从哪里发起。开发者要做的只是通过 API 描述自己的 Agent，把它接进业务场景——剩下的持久化、隔离和观测都由平台承担。人可以离开终端，把循环留在云端。
