提升Agent能力——上下文工程
简介
Loop Engineering 就是设计一个系统代替“你”来引导 Agent。这里所说的 Loop 可以理解为一个递归目标，你定义它，Agent 会迭代执行直到完成。是把 Agent 系统的工作范式从单次会话推进到持续运行系统。 1.ReAct 解决的是 Agent 在一次任务中的思考行动范式。 2.Loop Engineering 解决的是，如何把这样的 Agent loop 放进一个更高层次的工程系统里，让它可以被触发、被验证、并在必要时停止。 一个更简单的判断标准是：这个 Loop 的控制权在哪，谁来决定“继续”还是“结束”。总的来说，ReAct 这样的 Agent Loop 的控制中心仍然是模型本身；而 Loop Engineering 的控制权则外移到系统层。
从简单到复杂，常见的 Loop 系统有：
- 定期巡检任务：比如定期检查 CI、PR、bug、监控、工单。
- 事件驱动型任务：由 webhook、告警、用户反馈等变化触发。
- 目标易收敛的任务：如围绕测试通过（测试驱动）的软件开发任务。
- 优化搜索任务：围绕某个指标不断试验与逼近、保留更优解。
Loop Engineering 的核心意义：它不是取代 AI Coding，而是在 AI Coding 的基础上，进一步压缩了 Human-in-the-Loop 的比例。
用 Loop 的时候，需求和验证标准必须比原来写得更加明确。为什么？因为以前提需求哪怕模糊一点也没关系，模型先出个初版，人在 Human-in-the-Loop 的过程中可以不断纠偏、调整，靠人工反馈来保证最终结果的可靠性。但用了 Loop 之后，中间过程人不参与了，如果开头没把需求写清楚、没把验证逻辑定义明白，Loop 很可能从一开始就跑偏了，验证也不是按预想来的。跑了一大圈、烧了很多 token，最后出来的东西还是跟预期差十万八千里。
与/goal 对比
Agent 可以工作很久，也可以一起工作很多，但工程系统要能判断它什么时候真的可以停。
长程验证：AI Agent 从持续执行到工程化的收敛/goal 的价值是让 Agent 围绕一个目标持续推进，并在每轮结束后判断是否满足完成条件。但它更像接班机制，不是验证系统。 它能把任务继续交给下一轮，却不能替工程系统证明：执行轨迹是否完整、 变量状态是否可回放、分支和异常是否覆盖、step forward / backward 是否真的改变快照。所以，当目标只是“实现一个 time travel debugger”时，Agent 很容易生成一个看起来像完成了的项目：有结构，有 UI，有 README，有浅层测试。问题是，time travel debugger 的完成条件不在这些外观上，而在 trace、replay、状态恢复和语义一致性上。
如果 /goal 暴露的是长任务的纵向收敛问题，那么 dynamic workflows 暴露的是并行任务的横向归约问题。Claude Code 的 dynamic workflows 很有意思。它把长上下文硬撑这件事，转成了一个 JavaScript 编排脚本，由 runtime 在后台执行，调度多个 subagents。workflow 把 plan 放进 code，脚本保存循环、分支和中间结果，Claude 的上下文只接收最终结果。它可以用于 codebase-wide bug sweep、500-file migration、cross-checked research 这类任务。
任务状态从聊天窗口里移出来，进入脚本变量、阶段输出和 agent 结果。多个 subagents 可以并行搜索、审计、迁移、验证，最后由 workflow 合成结果。这很像 Agent 时代的 MapReduce：先切任务空间，再 fan-out 给 worker，再收集发现，再交叉验证，最后 reduce 成补丁、报告或结论。这里最贵的部分落在 reduce。workflow 如果只是并行搜索和摘要，其实不会带来足够可信的结果（它看起来很热闹，结果却未必更可靠）。几十个 subagents 一起跑，只是扩大覆盖面；如果没有交叉验证，也可能只是扩大错误面。只有当 claim 被抽取、证据被追溯、冲突被合并、失败被标记时，workflow 才开始具备工程价值。未来 Coding Agent 的竞争，会落到一个更具体的问题上：能不能把 worker 的结果归约成可信证据。并行只能扩大覆盖面。可信度来自验证关系。
长任务里最危险的地方在这里：Agent 没有失败，它只是把原始目标换成了当前最容易完成的目标。所以，long-running task 的工程重点，不在于让 Agent 更努力，或者多跑几个 session。任务每推进一段，都要能被验证。执行只是过程，收敛才是结果。没有验证点，长任务很容易变成长时间生成；有了验证点，它才开始像一个工程系统（把“继续做”变成“持续证明”）。长程验证不该被放到任务结束后，当作一份测试报告补上去。它应该出现在任务开始前、执行中、进入 Done 之前。
- 任务开始前，要有可检查的 done-condition，而不是一句愿望式目标。
- 执行过程中，要有 checkpoint，能说明当前状态为什么可以进入下一阶段。
- 多 Agent 并行之后，要有 reduce 机制，把结果归约成证据，而不是直接归约成总结。
- 进入 Done 之前，要留下 evidence bundle：命令、报告、截图、失败记录和未解风险。
/goal 让 Agent 不必一次做完，dynamic workflows 让 Agent 不必一个人做完。它们能不能进入工程交付，还要看另一组问题：目标是否有 done-condition，过程是否有 checkpoint，阶段之间是否有门禁，产物是否有凭证，失败是否能沉淀成下一次评估。
组成
一个最小的 Loop
- 一个 automation：按节奏触发，按明确条件停。
- 一个 skill：存下项目背景，省得每轮重讲。
- 一个状态文件：记下做完了什么、下一步干啥，明天续上。
- 一个闸门：自动拒绝坏活的测试 / 类型检查 / 构建。
loop 跑起来后，容易翻车的方式。
- 震荡。智能体反复修改代码，却无法收敛。这通常意味着目标不清晰、验证信号噪声太大，或者智能体一次编辑了太多内容。解决办法是缩小目标范围并减少 diff 大小。
- 上下文漂移。智能体继续基于过时假设工作，错过用户的新修改或新的失败。解决办法是在获得有意义的观察结果后刷新上下文，并避免把初始计划当成不可动摇的东西。
- 假装干完了。工程师 Geoffrey Huntley 管这叫 Ralph Wiggum 循环：Agent 提前发”完成”信号，活干一半就退。原因只有一个：没有硬闸门，缺少了测试和验收。
- 不安全的自主性。如果智能体可以运行破坏性命令、重写无关文件，或在没有评审的情况下推送变更，就可能造成严重损害。解决办法是权限控制、限定工具范围、对高风险操作进行人工批准，以及设置清晰的停止条件。
- 理解债务。loop 越快交付你没写过的代码，”仓库里有什么”和”你理解什么”的差距就越大。有一天，你得 debug 一个团队里没人读过的系统。
- 认知投降。 你慢慢不再自己判断，loop 返回啥就收啥。所以，即使有了Loop，也要读 diff、抽查闸门、不让 loop 碰架构。
场景
真正适合 Loop 的任务，需要有几个特点：
- 这件事是否会稳定重复出现？一次性的活，好 prompt 更划算。
- 完成与否是否能被测试、规则、评分器或独立的检验工具判定？测试、类型检查、linter，至少一个
- 任务失败的成本是否可控？
- 任务推进中需要的上下文能否被写进 skill、状态文件、知识文件？有日志、能复现、看得到哪崩了
- 你是否愿意为 Loop 的结果持续 review、迭代和治理？不打算，就别建
如果这五个问题里有四个以上的答案是肯定的，Loop 往往值得做。否则，你可能需要考虑更加可控的 Workflow、半自动化+人工辅助的流程，而不是无人值守的 Loop。
验证工程
长任务接下来要补的是更稳定的验证结构。运行时间继续变长，只会把这个缺口放大。
验证工程：验证工程是把目标、测试、可验证和记忆等组织成一个能持续收敛的工程 Loop。这个定义里，“验证”不是最后那个检查动作，而是让系统知道自己是否真的接近目标。
- 构建通过证明了工具链和代码语法在当前上下文里成立；
- 上传成功证明了固件可以抵达设备；
- 串口有输出证明了 firmware 认为自己执行到了某个状态；
- 摄像头看见屏幕并通过 OCR 识别到稳定 token，开始证明真实世界里的输出符合某种预期。
留下评论