MCPlato 中的 Loop Engineering：从提示词到留下 Artifact 的工作流

先给答案： Loop Engineering 不是写一个更长的提示词。它是设计一个工作循环，使其能够观察输入、保持状态、在检查点暂停、从失败中恢复、请求人工批准，并留下一个可检查的 Artifact。在 MCPlato 中，这个循环可以成为 Wand、Skill、Scheduled Task、channel workflow，或一组由 Sprite 协调的会话。

MCPlato 中 Loop Engineering 的封面插图

图 1：Loop Engineering 将一次性的 AI 请求转化为产出持久 Artifact 的工作周期。

Prompt Engineering 问的是：我该如何提问？ Loop Engineering 问的是：AI 应该如何安全地持续工作，直到 Artifact 完成？

这种区别很重要，因为真实工作很少在一次回应中完成。维护者需要带测试证据的修复；产品负责人需要带来源和时间戳的简报；运营团队需要带审计轨迹的报告包；业务负责人在外部或破坏性操作前需要审批。

因此，正确的设计单位是循环。

MCPlato 的循环设计方法

一个好的循环具备三个属性：

1. 可观察： 用户可以看到来源、状态、操作和结果。
2. 可恢复： 工作可以从检查点继续，而不是从头开始或重复自身。
3. 以 Artifact 为中心： 循环结束于某个可检查的产出：报告、diff、电子表格、包、决策日志、简报、草稿或审查记录。

MCPlato 与这一模型天然契合：

• Wand： 针对可重复工作的打包工作流，包含阶段、指导，以及面向 Artifact 的可见运行时。
• Artifact： 证明循环完成了有用工作的持久输出。
• Sprite： 可以把工作拆分到多个会话并把结果重新汇总的协调者。
• Skill 和 Distill Skill： 当一个循环证明有效后，可以再次调用的可复用知识。
• ClawMode： 让工作跨时间、channels 和后台上下文继续进行的方式。
• Scheduled Tasks 和 Channels： 递归循环的触发器和交付路径。
• 权限和检查点： 让有用的自主性保持受控的边界。

一个实用的 MCPlato 循环通常遵循九个步骤：

本文其余部分将这一方法应用到公共讨论和文档中出现的四个真实用户需求场景。

场景 1：GitHub issue → 修复 PR → 有证据支撑的 QA 报告

开源维护者已经在试验能够接手 GitHub issues 并尝试有边界修复的 agents。OpenHands 描述了一个面向仓库 issues 的 GitHub resolver，其 QA 文档则聚焦于验证变更，而不仅仅是产出代码。¹² 维护者需要补丁、测试，以及证明该变更足够安全、可以进入审查的证据。

一个相关风险出现在真实开发者反馈中。Continue 的一个 GitHub issue 报告称，某个 agent 反复在同一段代码上循环，而不是干净地停止。³ 这正是 Loop Engineering 必须处理的失败模式：没有停止条件的不受控迭代。

从 GitHub issue 到 QA 证据的循环

图 2：有边界的工程循环应产出 diff、验证日志和 QA 证据 Artifact，而不仅仅是声称 issue 已修复。

循环设计

在 MCPlato 中，循环应从 Artifact 开始，而不是从模型输出开始：

1. Issue 接收： 收集 issue、关联文件、复现说明和仓库约束。
2. 计划检查点： 在编辑前请求用户或维护者批准预期范围。
3. 补丁阶段： 在范围化工作区内做出最小的合理变更。
4. 验证阶段： 运行约定检查，记录失败，并且只在批准范围内重试。
5. 证据 Artifact： 生成 QA 报告，包含已改文件、测试日志、相关时的截图，以及剩余风险。
6. 审查门： 准备 PR 或 MR 描述草稿，但不要把工作表述为已合并或已接受。
7. Distill： 如果模式有效，将其转化为可复用的仓库 QA Skill 或团队 Wand。

MCPlato 实现模式

由 Sprite 协调的设置在这里很有用。一个会话可以读取 issue 并起草计划，另一个会话可以检查仓库，另一个可以验证，最终会话可以组装 QA 证据 Artifact。Wand 可以封装这些阶段，让团队不必为每个 issue 重新发明循环。

关键护栏是停止条件：验证预算耗尽、同一失败重复出现，或变更将超过批准范围时，循环应停止。Artifact 应准确说明发生了什么，而不是隐藏不确定性。

Artifact： diff 摘要、测试日志、QA 证据报告、PR/MR 描述草稿，以及风险列表。

场景 2：交付完整结果的定时研究简报

递归研究是另一个 “prompt once” 过于薄弱的地方。讨论定时 AI 任务的用户曾要求通过邮件发送完整结果，而不仅是完成通知。⁴ Zapier 对 ChatGPT scheduled tasks 的概览描述了让 ChatGPT 在未来或按递归节奏运行提示词的模式。⁵ 实际缺口在于交付质量：有用的定时循环应产出带链接、时间戳、变化量和行动项的简报。

定时简报交付循环

图 3：定时循环应收集来源、去重、综合、检查引用，并把完整简报 Artifact 交付到正确 channel。

循环设计

MCPlato 简报循环可以是：

1. 定时触发： 每日、每周，或在固定会议前运行。
2. 来源收集： 收集已批准的来源，例如已保存 URL、类似 RSS 的 feed、文档页面或工作区材料。
3. 相关性和去重： 移除重复公告和低信号项目。
4. 综合： 用稳定格式撰写简报。
5. 引用检查： 确保每个具体主张都能回指到来源 URL。
6. Artifact 输出： 创建带日期的简报，包含来源列表和行动项表格。
7. Channel 交付： 发送完整 Artifact，或发送带 Artifact 链接的简洁摘要。
8. 跟进： 让用户请求更深入分析、分配下一步行动，或 distill 简报循环。

MCPlato 实现模式

这正是 Scheduled Tasks、ClawMode 和 channels 协同发挥作用的地方。Scheduled Task 触发循环；MCPlato 收集已批准的上下文，产出 Artifact，并将其交付到工作区或 channel。当简报风险较高时，Sprite 可以协调不同 workers 分别负责来源收集、综合和引用审查。

简报循环绝不应假装读过实际没有访问的来源。当信息不可用时，Artifact 应包含 “未找到” 或 “未检查”。这种诚实状态比一段精致但不可验证的文字更有用。

Artifact： 每日或每周简报、来源列表、行动项表格、相较上次运行的变化，以及引用备注。

场景 3：浏览器登录、参数填写、报告下载和本地整理

许多业务工作流仍然存在于网页背后，而不是干净的 API 之后。Stack Overflow 上有问题询问如何自动登录网页并下载报告。⁶ 在 Python.org 的讨论中，一位用户描述了为大约 50 个客户下载报告，每个客户 3 到 4 份报告，每周手工耗时 3 到 4 小时。⁷ 这是一个真实的运营痛点：重复、受浏览器约束，并且很容易出错。

浏览器报告下载循环

图 4：浏览器自动化应把人工登录边界与重复的参数、下载、验证和整理步骤分开。

循环设计

一个安全的浏览器报告循环应明确访问边界：

1. 需求接收： 列出客户名称、报告类型、日期范围和预期文件。
2. 访问边界： 决定哪些事项必须由用户手动完成，例如登录、MFA 或 CAPTCHA。
3. 发现和 API 检查： 在使用浏览器自动化前，确认是否存在文档化导出或 API。
4. 浏览器自动化： 填写参数、启动下载，并记录每一步。
5. 验证： 检查文件名、时间戳、预期数量和明显为空的文件。
6. 转换： 规范化文件夹，在适当时转换格式，并生成摘要。
7. 异常报告： 列出缺失下载、失败客户或发生变化的页面。
8. 定时重复： 只按节奏运行可重复部分，并在凭据或页面结构变化时设置人工检查点。

MCPlato 实现模式

不应把 MCPlato 描述成 “它可以处理任何网站”。网站各不相同，登录会变化，策略很重要，有些流程会有意抵抗自动化。更好的表述是：MCPlato 可以帮助围绕被允许、可重复的部分设计受控循环。

用户可以处理登录检查点。随后 AI 循环可以在已批准的浏览器会话中运行，下载报告、整理本地文件，并产出异常 Artifact。如果网站发生变化，循环应停止并报告不匹配，而不是猜测。

这类循环在成功运行几次后通常值得 distill 成 Wand。Wand 会成为团队可重复的 “月度报告包” 流程，具有清晰阶段和输出文件夹，而不是脆弱的转录记录。

Artifact： 已下载报告包、成功/失败列表、规范化文件夹结构、摘要电子表格，以及异常报告。

场景 4：高风险工具调用的人工批准

Loop Engineering 不只是关于做更多事。它也关于知道何时停止。一个 LangGraph issue 请求一种 approval-node 模式，让用户可以在执行前批准、拒绝或修改操作。⁸ LangChain 的 human-in-the-loop 文档描述了围绕工具调用暂停以供审查。⁹

风险示例很常见：写入文件、执行 SQL、删除数据、发布内容或发送电子邮件。这些不只是 “agent steps”。它们是业务操作。

人工批准门循环

图 5：好的循环会在高风险操作前暂停，记录决策，并在执行后留下证据。

循环设计

高风险操作循环应如下所示：

1. 风险分类： 判断下一步操作是只读、可逆、面向外部、破坏性还是财务相关。
2. 起草操作： 准备文件变更、SQL 语句、电子邮件、帖子或命令，但不执行。
3. 批准检查点： 向用户展示预期操作、原因、预期影响和回滚计划。
4. 用户决策： 批准、编辑、拒绝，或请求更多上下文。
5. 执行： 只运行已获批准的操作。
6. 证据 Artifact： 记录决策、前后 diff、执行结果和剩余风险。

MCPlato 实现模式

MCPlato 的循环词汇让这件事很直接。Wand 可以把起草与执行分离。批准前权限可以更窄，确认后才扩大。Sprite 可以请另一个会话先审查拟议操作，再展示给用户。ClawMode 和 channels 可以把批准请求带到用户正在工作的地方。

循环绝不应把危险默认值正常化。删除数据、发送外部消息、更改账单或发布内容，都应需要一道门，除非用户已经为该操作明确设计了可信、受边界约束的工作流。

Artifact： 批准记录、变更计划、前后 diff、消息或电子邮件草稿、执行证据，以及风险列表。

如何把成功循环转化为可复用的 MCPlato 能力

循环成功一次后，不要立刻把一切自动化。先问：

1. Artifact 有用吗？ 如果输出没有帮助用户做决策或完成工作，循环还没准备好。
2. 检查点放在了正确位置吗？ 过多检查点会让循环令人烦躁；过少则会不安全。
3. 不同用户能否在没有隐藏上下文的情况下运行它？ 如果答案是否定的，就记录所需输入和假设。

然后选择正确的 MCPlato 封装路径：

MCPlato 主分支的最新方向强化了这种从聊天到打包、可观察工作的转变。Wands 让工作流变得明确。面向 Artifact 的运行时视图让结果保持可见。Wand 编写和迭代指导使成功循环更容易转化为可复用能力。Skills 和 Distill Skill 保留方法中可重复的部分。

原则很简单：不要只保存答案；要保存创造答案的工作循环。

风险和护栏

Loop Engineering 很强大，但它会以可预测的方式失败：

• 失控迭代： 添加预算、重复失败检测和明确退出状态。
• 虚假完成： 要求带日志、来源或前后证明的 Artifact。
• 权限蔓延： 按阶段分配权限。
• 隐藏上下文： 在 Artifact 中记录假设。
• 过度自动化： 为高风险步骤添加批准检查点。
• 脆弱的浏览器流程： 使用验证和异常报告，而不是静默猜测。
• 引用漂移： 要求来源时间戳和引用审查。

好的循环不是自主性最多的循环。好的循环是在完成 Artifact 的同时，让其工作足够可见、从而值得信任的循环。

常见问题

什么是 Loop Engineering？

Loop Engineering 是把 AI 工作设计为有状态流程，而不是一次回应的实践。循环定义目标、输入、阶段、权限、检查点、恢复路径和最终 Artifact。

它与 Prompt Engineering 有何不同？

Prompt Engineering 改进指令。Loop Engineering 改进围绕指令的工作系统。更好的提示词可能产出更好的第一版答案。更好的循环可以继续、验证、暂停、恢复并交付。

MCPlato 适合放在哪里？

当工作跨越会话、文件、浏览器上下文、计划、channels 和持久输出时，MCPlato 很有用。它的循环词汇——Wand、Artifact、Sprite、Skill、ClawMode、Scheduled Tasks、channels、权限和检查点——有助于把有用的一次性工作转化为可重复能力。

每个 AI 任务都应该变成循环吗？

不会。简单问题可以继续是简单问题。当任务长期运行、重复、高风险、证据密集或以 Artifact 为中心时，再使用 Loop Engineering。

Loop Engineering 能保证正确性吗？

不能。它提升可观察性、可恢复性和审查能力。循环仍可能使用糟糕来源、做出错误假设，或在工具变化时失败。这就是引用、检查点和异常报告重要的原因。

参考文献

Footnotes

1. OpenHands：GitHub 中的开源编码 agents，修复你的 issues ↩

2. OpenHands 文档：QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community：通过电子邮件发送完整 ChatGPT task 结果，而不仅是通知 ↩

5. Zapier：如何使用 ChatGPT scheduled tasks ↩

6. Stack Overflow：有没有办法自动登录网页并下载报告？ ↩

7. Python.org 讨论：使用 Selenium 从网站自动下载报告 ↩

8. LangGraph issue #8026：ApprovalNode ↩

9. LangChain 文档：Human-in-the-loop ↩