“帮我排查今天早上 user-service 接口变慢的原因，并把结果发给负责人。”这类请求没有固定答案：先查监控、日志还是 Heap Dump，要看前一步拿到了什么证据。即使已经发现慢 SQL，也还得判断要不要继续查执行计划、怎样组织结论、是否可以发出通知。
聊天模型可以给出一份排查清单，却不会自己把这条路径走完。要完成任务，模型需要选择工具、读取工具结果，再据此决定下一步或结束。AI Agent 处理的就是这段连续的决策与执行过程。
工具接得越多，执行路径越不能随意放开。订单扣库存、审批流这类步骤明确的工作，仍应由传统程序或 Workflow 控制；只有中间步骤依赖实时证据、无法预先写死时，才需要让 Agent 参与判断。
File not found
长任务一跑起来，很快就会撞到几件硬约束：上下文窗口有上限，Token 账单会一路涨，Session 结束后如果没有落库，上一轮轨迹默认就跟进程一起消失。模型即使能完成当前推理，也缺少保存和复用历史记录的位置。
记忆层需要同时保住当前对话的关键事实，并让新 Session 能取回用户偏好、背景和历史决策。文章依次讨论记忆的表征和功能分类、读写生命周期、短期与长期实现、主流产品和检索优化，以及 Markdown 记忆。滑动窗口怎么裁、overload 怎么卸，和同站的 《上下文工程(Context Engineering) 是什么？和 Prompt Engineering 有什么区别？》 有交集，两篇可以对着看。
上下文窗口能装下更多资料，不代表 Agent 会稳定利用这些资料。一次调用里混入过期状态、无关日志或几十个相似工具描述后，模型仍可能漏掉真正影响决策的条件。
Context Engineering 处理的就是调用前的信息组装：哪些规则进入消息，哪些证据按需检索，哪些工具在当前阶段可见，历史何时压缩，原始结果如何保留引用。长任务还要处理跨窗口的状态交接，避免摘要后丢失约束、版本号和未完成事项。
Can.ac 的一次编码评测中，同一个模型仅替换文件编辑接口，得分就从 6.7% 升到 68.3%。模型参数没有变化，差别出在接口提供了什么操作、怎样返回结果，以及错误能否被下一步利用。
这类差异也解释了常见的 Agent 故障：重复调工具、忽略约束或在长任务中丢失状态，往往不能只靠换模型或补一句提示词解决。工具接口、执行环境、反馈和恢复机制同样决定任务能否继续。
Harness Engineering 讨论的就是这套模型外部系统。下文先拆开它的组件与分层，再对照 OpenAI、Anthropic、Stripe 和 Mitchell Hashimoto 的实现取舍。
CI 失败后，Agent 可以读失败日志、定位相关文件、运行最小测试集，再把排查结果写回 Issue。第一次排查没有收敛时，任务还会遇到一个更实际的问题：下一轮由谁启动，继续读哪些材料，什么时候该停下来交给人处理？
Loop Engineering 讨论的就是这段外层流程。它负责把 Agent 的一次次执行接起来：CI、PR 或定时任务触发下一轮，项目规则和相关证据进入上下文，测试与审查决定结果是否可信，状态记录让后续任务可以从上次停下的地方继续。
从公开讨论看，这个名称在 2026 年 6 月上旬 开始热起来，Addy Osmani 于 6 月 7 日发表了相关文章。Claude Code 与 Codex 中的 /loop、/goal、Automations 等能力，配合 Skills、Sub-agent、工作区隔离和 MCP/Connector，已经能组成类似流程。
同一个 Git 工具接到 Claude Desktop、Cursor 和自建 Agent 时，往往要各写一层适配。工具参数、鉴权方式或版本一变，接入它的多个客户端都得跟着改。
MCP 约定外部系统以 Server 形式暴露能力，支持该协议的 Host 通过 Client 发现并调用这些能力。它处理的是工具和数据源的接入；模型如何决定调用、任务如何编排，仍属于 Function Calling 和 Agent 的职责。
把背景、限制和示例全部堆进一条 Prompt，模型不一定更稳定。重复信息会增加输入成本，互相冲突的要求还会让输出偏离任务。Prompt 应该写清任务、必要背景、约束和输出格式，其余资料按需进入上下文。
前置知识：本文默认你已经理解 Token、上下文窗口、Temperature、Top-p 等 LLM 底层概念。如果还不熟，可以先看《LLM 运行机制：Token、上下文窗口与采样参数怎么影响输出》。
一次 Code Review 可能要看架构、安全、性能和项目约定。临时把这些规则放进 Prompt，换个会话后又要重新粘贴。
全局项目约定可以留在 AGENTS.md；Review 的检查顺序、检查项和参考资料应随 Review 任务加载。Skill 为这部分内容提供了独立入口。
Skill 是可被 Agent 发现、按需读取的任务说明。接口返回格式、日志字段、慢 SQL 的排查路径、Review 的关注顺序，都可以写进 SKILL.md。
Skill 本身不提供工具能力。它解决的是“这类任务该按什么规则做”，由宿主在任务命中时把对应说明交给 Agent。
Camunda、Temporal 等传统引擎同样支持事件、分支、重试和补偿。AI 工作流新增的麻烦在于，部分节点的输出由 LLM 生成，“结果是否达标”也可能需要模型或评分器在运行时判断。流程因此经常出现回边：生成、评估、修改，再回到评估。
Workflow 描述任务怎样完成，Graph 用 Node、Edge 和 State 表达执行结构，Loop 则是 Graph 上的回溯控制。下面沿着文章审核示例说明三者如何配合，并用 Spring AI Alibaba Graph 展示状态更新和条件边。
单轮对话能回答问题，但很难稳定地交付结果。线上真实任务很少是“问一句答一句”就完事——检索信息、调用工具、输出结构化结果、校验格式、失败重试、不满意再来一轮，这些步骤串起来才叫交付。靠一段超长 Prompt 把所有逻辑塞进去，早晚会炸。你需要的是一种可分支、可循环、可观测的执行路径。
本地调通一个大模型 API 只说明网络和参数基本可用。接进真实业务后，首字延迟、半截 JSON、429、取消和重复执行都要处理：
{"answer": "根因是。