多项目 AI Agent 管理的规律性运维框架

dev.to · AI#Agent#系统架构#最佳实践

Editor brief · 编辑速览

通过三个实际产品展示如何用 preamble.md、automations.json 机制实现 Agent 知识持久化和规律执行，解决记忆隔离问题。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

同时用 AI Agent 并行推进多个项目，会产生一种反直觉的现象：如果没有一套能够产生复利效应的基础设施，每次运行都得从零开始。记忆被限制在项目内部，已经发现的模式无法迁移，而推进节奏则完全取决于人什么时候有空。接下来要介绍的，正是解决这一问题的基础设施，以及为什么规律性是它发挥作用的首要条件。

本文基于三个正在运行的项目：Bloomii，一家关注社会与环境替代方案的建设性新闻媒体；Kalceo，一款面向法国建筑承包商的监管类 B2B SaaS；以及 Ekioo，支撑本文的 Agent fleet 研发项目。这三个项目全部运行在 KittyClaw 上——一个面向 AI Agent 的看板编排器。

编排式项目的结构

每个项目都有一个 .agents/ 目录，其中包含四类元素：

.agents/
├── preamble.md          # context injected into every agent run
├── automations.json     # trigger pipelines
├── {agent}/
│   ├── SKILL.md         # stable domain instructions
│   └── memory.md        # accumulated learnings, run after run

preamble.md 是维持一致性的核心载体。它包含共享规则，例如 git 工作流、commit 规范和 API 访问方式，并会在启动时注入每个 Agent 的上下文。已经写进 preamble.md 的内容，无须在每个 SKILL.md 中重复。

automations.json 用于定义流水线。核心自动化流程 assignee-dispatch 会在 ticket 被分配给某个 Agent 并进入 Todo 后，立即执行三个操作：

{
  "id": "assignee-dispatch",
  "trigger": { "type": "ticketInColumn", "columns": ["Todo"] },
  "conditions": [
    { "type": "assignedTo", "slugs": ["programmer", "content-writer", "qa-tester", "..."] },
    { "type": "ticketCountInColumn", "columns": ["InProgress"],
      "sameAssignee": true, "operator": "==", "value": 0 }
  ],
  "actions": [
    { "type": "moveTicketStatus", "to": "InProgress" },
    { "type": "runAgent", "agent": "{assignee}", "model": "claude-sonnet-4-6" },
    { "type": "commitAgentMemory", "agent": "{assignee}" }
  ]
}

ticketCountInColumn == 0 这一条件可以避免并行失控：只要某个 Agent 还有一张进行中的 ticket，它就不会开始处理新的 ticket。最后一个操作 commitAgentMemory 会在每次运行后自动持久化 Agent 的记忆——这正是产生复利效应的关键。

将记忆作为进步工具

大多数 AI Agent 配置仍然是无状态的，而 memory.md 引入了一种结构化的持久状态。每个 Agent 都会维护一份经验文件，并使用 [+N] 计数器记录每条经验被再次应用的次数：

## API / tooling [+5]
- curl on Windows mangles UTF-8 in JSON bodies.
  Use python3 urllib.request instead. [+2]
- PR creation: gh not available;
  az repos pr create has permission errors. [+2]

## SVG inline in Markdown [+3]
- NEVER use <marker> + marker-end="url(#id)" in inline SVGs. [+3]
- Draw arrowheads as explicit <polygon> elements.

这个计数器有两个作用：一是显示哪些经验真正有价值，因为它们会反复出现；二是指导知识沉淀——当某个条目达到 [5+] 时，就将其迁移到 SKILL.md，成为稳定规则。计数为 [0] 的条目则会被删除。

SKILL.md 与 memory.md 之间的区别是结构性的：前者存放很少修改的稳定规则，后者存放每次运行都会更新的活跃经验。这种区分可以防止记忆文件沦为无所不包的杂物箱，并强制我们谨慎判断哪些内容值得保留。

跨项目的复利效应

Agent 会从错误中学习——某个 Agent 一旦遇到过某个问题，memory.md 就能确保它不再重蹈覆辙。但真正的跃迁，发生在不同项目开始共享完整能力之后。

共享图片生成能力

Bloomii 的 content-writer 需要一张插图，Ekioo 的 content-writer 需要一张封面。两者都不需要知道 gpt-image-2 如何工作，不需要管理 API key，也不需要操心速率限制。

中央 Workspace 中有一个处理器，通过每 10 分钟运行一次的 cron 任务工作。任何项目的 Agent 都可以通过 image-enqueue.mjs 提交请求，拿到 ID 后继续处理其他工作。处理器负责管理队列，在达到配额限制时暂停，并在条件允许后自动恢复。图片准备好后，Agent 会收到通知。

node C:/IA/Workspace/.agents/tools/image-enqueue.mjs \
  --prompt "..." --output path/to/cover.webp \
  --project bloomii --ticket 189

一个工具、一个处理器、N 个消费项目。即使增加第六个项目，也不需要任何额外配置——只需调用 image-enqueue.mjs。

Bloomii、Ekioo、Kalceo 的 Agent → image-queue.json 单一队列 · cron 每 10 分钟运行 → 自动速率限制 → gpt-image-2 CDP 处理器 → .webp

集中式邮箱——自动分发

所有项目共享同一个邮箱，并通过 VizMail 暴露服务。VizMail 是一个本地 HTTP server，提供 40 多个 REST endpoint。收到邮件后——无论是 Kalceo 客户的回复、Bloomii 读者的反馈，还是 Ekioo 的联系表单——系统都会自动将其分发到对应项目，创建为一张 KittyClaw ticket。随后，合适的 Agent 会在无须人工介入的情况下接手处理。

最终效果是：只需监控一个邮箱，无须任何人工分类，而且每个项目都能将与自身相关的邮件转化为可由 Agent 执行的任务。

IMAP 单一邮箱 lain@ekioo.com → VizMail 分类与分发 → 为各项目创建 KittyClaw ticket：Kalceo 客户回复 → ticket；Bloomii 读者反馈 → ticket；Ekioo 联系表单 → ticket

集中式 X 品牌运营

四个项目共同为一个 X 账号（@LainAgent_AI）提供内容。每个项目都有自己的发布工具 x-post-tweet.mjs，但编辑策略统一保存在中央 Workspace 的 x-strategy.md 文件中，包括内容支柱、表达风格和互动规则。

community-manager 负责起草，Lain 负责审批。不会因为运营四个无人问津的账号而分散受众，而是由四种不同的内容来源，共同供养一个持续建立权威性的账号。

Ekioo · AI/Craft；Kalceo · BTP；Bloomii · Green → 内容支柱 → x-strategy.md 统一风格 · 审批流程 → community-manager + Lain → @lainagent_ai 单一账号 · 权威性 → VizMail · Tooling

中心辐射式知识库

中央 Workspace 提供共享基础设施：API 文档（KittyClaw、Brevo、Chrome CDP）、集中管理的凭据以及 CLI 工具。每个项目则维护自己的领域知识库——Kalceo 保存 BTP 法规和手工业者的痛点，Bloomii 保存编辑研究资料包和分发指南。

Kalceo 的 Agent 发送 newsletter，与 Bloomii 的 Agent 安排 LinkedIn 帖子时，使用的是同一个 Brevo token、同一份文档和相同的调用模式，却无须知道对方项目的存在。基础设施知识只编写一次，就能在各处复用。

中心 hub——Workspace：knowledge/ · tools/ · credentials；KittyClaw API、Brevo API、Chrome CDP → 辐射节点——项目领域：Kalceo 的 BTP 法规、手工业者痛点 · 报价；Bloomii 的编辑支柱 · 来源、分发资料包；Ekioo · VizMail 无领域知识库 → 统一使用中心能力

将节奏作为健康信号

所有项目每周总计处理 30 到 50 张 ticket。这个数字不是生产力目标，而是系统健康状况的指标。

如果某个项目的 Todo 列不断积压却没有被清空，信号就很明确：要么 backlog 的优先级安排不合理，要么项目缺少适合处理队列中任务的 Agent。每周稳定的处理节奏，会让这种失衡立刻显现出来。

evaluator Agent 会在每张 ticket 关闭后计算评分，包括首次交付成功率、反馈遵循程度和交付质量。这些指标用于衡量复利效应是否真正生效——首次交付成功率不断提高，意味着 Agent 在一次又一次运行中持续进步；如果该指标停滞不前，则说明记忆已经得不到新的输入。

一个不能规律运行的 Agent，无法积累可用的记忆：它每次都会重置，重复犯下相同的错误，提出相同的澄清问题。规律性并不只是一种发布纪律——它是整个系统得以学习的必要条件。

每个 Agent 所需的基础设施可以归结为四个文件：preamble.md、automations.json、SKILL.md 和 memory.md。真正让它发挥作用的，是持续向系统输入经验的纪律：每次运行后提交记忆（commitAgentMemory 操作会自动完成这件事），删除计数为 [0] 的条目，并将达到 [5+] 的经验提升到 SKILL.md。

真正重要的规则只有一条：绝不要连续两周停摆。安静一周不会破坏节奏；连续两周则会破坏 Agent 的记忆、项目的一致性以及 SEO 信号。

一致性第一，数量第二。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。