Loop Engineering：把 Agent 做成可改进的系统

企业级知识问答 Agent 上线后，常见症状往往很像：漏依据、污染上下文、生成物不合规。模型换了一代又一代，这些问题却未必跟着消失。于是判断很容易滑向一句：“是不是模型又不行了？”

真正需要回答的，通常是下面三个问题：

1. 1. Loop Engineering（闭环工程）是换模型的对立面吗？ 还是换模型之外必须工程化的那一层？
2. 2. 把上下文塞得更满，是不是更稳妥？ 还是窗口越满，越难做出可靠决策？
3. 3. 出了评测报告，算不算闭环？ 如果改完提示无法回滚、失败步骤看不见，报告有什么用？

我会用同一条业务故事回应这三个问题：销售先问跨境投资与激励政策的门槛与时间线，再要求根据刚才的讨论生成一份面向投资人的架构演示文稿。冲突会依次出现；解法不在模型名字里，而在上下文装配、记忆取回、工具约束与外环回写。

闭环工程总览：内环完成当次请求，外环降低重复失败

先澄清几个术语，避免后文混用。

Loop Engineering（闭环工程）：用内环与外环组织 Agent 系统。内环负责单次请求的可靠完成；外环依据运行轨迹改进系统提示（下文称 SOUL）、配置、工具策略或检索参数，经门禁发布后再回流内环。

内环：一次用户请求从提问到回复的完整过程——装配上下文、模型推理、调用工具、通过护栏、生成回答。跑完之后，中间过程可以丢弃。

外环：观察多次内环留下的记录——哪一步慢、哪一步失败、回答质量如何——据此决定是否调整 SOUL、配置、工具策略或检索参数；变更经门禁验证后再发布，并进入后续内环。

Context window（上下文窗口）：本轮决策中模型实际读到的内容。窗口有限，通常由四块拼起来：SOUL（人格、规则与边界）、当前用户输入、裁剪后的对话与工具摘要、按需取回的记忆。可以把它形象地理解成 Working Memory（工作记忆）。

它们之间的关系可以理解成：

• • 模型主导“能不能想”；闭环工程负责“看见什么、能动什么、失败了怎么改”。
• • 内环负责当次任务；外环负责降低下次重复踩坑的概率。
• • 内环追求“这一轮答对”；外环追求“同类失败别再出现”。

模型像发动机，闭环工程像底盘、刹车与持续改版的工程流程。发动机再强，装配混乱、护栏失灵、失败不可追溯，系统照样翻车。

这个类比有边界：真车的底盘不会每开一公里就改图纸；Agent 的外环却要持续改 SOUL 与配置，而且必须可回滚。类比只说明“别只盯着模型”，不替代外环如何工程化。

回到第一个问题：闭环工程不是换模型的对立面。换更强模型仍然有价值；但若内环外环未工程化，更强的模型只会把同样的坑挖得更深一点。

上下文工程：context window 是预算，不是档案馆

第二个问题的前半句：上下文是不是越多越好？

答案：不是。Context window 的目标是“下一步决策够用”，不是把整条审计日志塞进模型眼前。完整运行日志可以另存，供外环复盘；本轮窗口则要有预算。

窗口内通常只有四块：SOUL、当前用户输入、裁剪后的对话与工具摘要、按需取回的记忆。旁边还有三类长期记忆——程序记忆（如何按规范执行）、语义记忆（依据从何而来）、情节记忆（本场对话进展到何处）——需要时才注入窗口。

若把窗口比作工作台、把长期记忆比作档案架，可以这样对照：

• • 工作台管当次决策；档案架管长期可取回。
• • 工作台怕塞满；档案架怕丢源。

台面太小，塞多了东西就找不到扳手。类似的，工程上要管的，是 context window 的装配预算与注入边界。

常见做法包括：SOUL 拆成长期稳定的规则块与随请求变化的块，让稳定前缀能被缓存；按轮次与长度裁剪历史；给主循环设步数上限，防止空转。对“步骤多、中间稿重、失败可局部重试”的任务，隔离往往比压缩更管用——subagent 自带独立 SOUL 与参考材料，主会话只下发任务、回收摘要。

要让 Prompt Cache 稳定命中，并避免长链路生成污染主会话，关键只有两件事：静态与动态分开，重的生成任务交给 subagent。

Subagent 隔离：长链路生成不要污染主会话

销售在同一会话里连续追问：某地家族办公室的设立条件、某项税务激励的资金门槛、专业人员与本地支出要求，以及申请与审批时间线。系统已完成多轮检索与结构化答复。用户随即说：根据刚才的结论，生成一份面向投资人的上市路径架构演示文稿，包含几种常见结构与合规要点。

若把整段生成留在主对话里，幻灯片草稿、失败重试与改稿会覆盖此前关于门槛与时间线的讨论。用户再追问“刚才说的资金门槛是否必须在申请时就达到”，关键结论可能已被生成中间产物挤占。

根因很具体：静态与动态搅在一起时，动态噪声吃掉窗口预算；“生成多页架构文稿”与“继续核对政策细则”在争夺同一条 context window。

解法对应三层：分离 SOUL 的静态与动态部分；预算化裁剪并设步数上限；把生成文稿交给 subagent，中间稿留在 subagent 侧，主会话保持可续聊。

主会话像会议室，subagent 像打印间。打印间再乱，会议室还要能接着开会。这里的“房间”对应的是主会话与 subagent、两份上下文预算；隔离的是 context window，不是物理空间。

记忆分层：程序、语义、情节不可混同注入

第二个问题的后半：会话里聊过的结论，能不能当正式依据？

用户提问某地家族办公室的设立与时间线，并点名一项税务激励的申请流程。系统改写查询、拆分子查询，并行检索企业内部知识库与公开网页。召回结果里既有语料中的制度解读，也有网页侧更新的门槛信息；检索链路同时施加了用户组可见性过滤。

次日续聊：“按昨天那套门槛，帮我核对开业后向监管机构申报的时限。”

若把昨日口头归纳与知识库 / 网页条文混同注入，模型可能把推演当正式依据，或把旧语料数字当作现行规则。政策类内容又有时效性：语料与网页在同一门槛上可能冲突。若可见范围由模型自行拼接过滤条件，还会漏检或越权。

三类记忆的权威级别需要明确区分：

口头结论像便签，制度原文像盖章文件。便签可以提醒你，盖章文件才能当依据。

解法：情节走会话层，语义走知识库；写入时标注来源与用途；时效冲突时显式处理不确定性；重排序后只送入靠前依据；可见性由服务端强制执行。查询意图可以交给模型改写；“谁能看见什么”必须在服务端按身份预过滤，模型不得改写这条边界。

工具与护栏：先感知，再执行或委托

同一会话两段任务：先就家族办公室与激励政策做混合检索与网页补充，整理资金、人员、本地支出与申报时间线；再要求输出四页演示文稿（投资架构、几种上市路径对比、投资者风险、合规关注点），其中一页须画出几种结构的可视化架构图。

工具按三条线组织：

• • 感知：改变模型看见的信息——查知识库、读技能说明、必要时取网页；不直接改用户最终文件。
• • 执行：在隔离环境中跑代码、生成图表与中间文件，得到可校验产物。
• • 委托：主循环把长链路生成整段交给 subagent，只回收摘要。

对照关系可以写成：感知改看见的；执行改产物；委托改谁来干。

若感知不足就进入生成，架构页会缺合规依据，出现空洞或编造。若在主会话硬性完成多页文稿与图表代码，草稿回流，前面的问答上下文被污染。若生成类技能尚未加载就调用工具，仅靠提示里的“请先阅读规范”拦不住。

技能门控要把“请先阅读规范”从愿望变成控制：规程未加载，相关工具直接失败。护栏则落在路径上——入口权限与限流、隔离执行与预检、生成结果结构校验、依据不足时说明缺口、回复前再检查。

愿望写在提示里，控制写在路径上。前者靠自觉，后者靠失败。

系统级验证：可观测定位失败，门禁回写配置

第三个问题：评测报告算不算闭环？

多用户反馈某类架构演示文稿生成失败或版式不合格。第一反应往往是怀疑模型。可观测显示：大量失败停在幻灯片代码的结构校验——模板或校验规则已更新，subagent 在空转重试；另有一部分卡在检索超时，与生成质量无关。

还有一次，为压测质量更换了子任务模型配置并修改系统提示后直接上线。两周后出现“架构图缺层、合规页数字漂移”，却无法追溯从哪一版提示或配置开始。

表面症状像模型变差。根因在外环缺失：失败步骤不可见，分不清检索超时、结构校验失败与真正的生成质量问题；发布未绑定版本，变更无法以可追溯方式回流内环。

外环路径可以写成：可观测 → 评价与诊断 → 门禁 → 发布版本 → 回流内环。健康度（超时、报错）与质量（是否达标）是两套问题；能自动判定的条件优先做门禁。

外环若止于报告，改进进不了生产。有效产出是可回滚的 SOUL、配置或检索参数。

看不到步骤，就只能归因于模型；看见步骤，才知道该改校验、改超时，还是改提示。

结语：三个问题的答案

1. 1. 闭环工程是换模型的对立面吗？ 不是。它是换模型之外必须工程化的那一层；没有它，更强模型只会把坑挖深。
2. 2. 上下文塞满更稳妥吗？ 否。Context window 是预算；隔离常常比压缩管用；便签与盖章文件不能混同注入。
3. 3. 评测报告算闭环吗？ 不算。看不见失败步骤、改完无法回滚，报告只是旁观；终点应是可发布的 SOUL 与配置版本。

可带走的五条：

1. 1. 硬约束放在环外，智能放在环内。
2. 2. Context window 先定预算与收束，再打磨提示措辞。
3. 3. 重任务交给 subagent，主对话保持可续聊。
4. 4. 程序记忆是开关，语义记忆是底座，情节记忆是连续；三者不可混存混用。
5. 5. 没有回写的评测不是闭环。

换更强模型仍然有价值。但若内环装配混乱、外环看不见失败步骤、改完提示无法回滚，更强的模型只会把同样的坑挖得更深一点。