我如何用 Git 管理工作流管理多个 Agent

可能有成百上千篇类似的帖子。但我想分享一下我如何创建和管理一支代理团队的工作流程。过去几个月我取得了巨大成功。

我依赖某种索引，保存每一条经纪人的工作。每个计划都是一个单独的标记文件，人类可读，可以与其他同事或其他经纪共享。

这些计划存在专用仓库，所有云代理（当然还有同事）都能访问。最初，随机代理会创建和管理这些计划，但后来我改用长期运行的代理。

这些被称为协调者，他们负责读写仓库（后面会详细说）。在 git 仓库里有它们的好处是代理知道如何交互，我可以免费获取历史记录。

布局

一切都始于技能/plan-init.你只需在存放计划的仓库里调用一次，然后就不再调用它。这项技能会为你的目录设置管理代理所需的文件夹，并且README.md这就是下一步和开放内容的索引。

这将创造出以下内容：

plans/
  README.md
  drafts/
  next/
  open/
  done/
  discarded/

现在，让我们开始使用它。假设你在Slack上，并且有人写了这条消息：

"Hey @fatih, the service foo caused an alert and clients started receiving 500, could you look into this?"

注意它也可以是自动化，但假设是我们触发了它。我们将手动写下来：

@cursor /plan-add investigate why the service is getting 500, also check PR 123, it might be related

这就形成了一个新的计划，称为hub-service-500.md并将其归入drafts/文件夹。那个hub-前缀为工作区域;其余为短字条：

drafts/
  hub-service-500.md
next/
...

/plan-add这没什么特别的，只是确保你所有的想法或想法都被保存下来的方式。你看到某样东西不想忘记，然后在光标里写下：/plan-add a way to run service bar concurrently.

现在我们的文件夹变成了：

drafts/
  hub-service-500.md
  hub-concurrent-bar.md
next/
...

我们所做的只是把未来可能想买的东西搬到......drafts/文件夹。你想释放你的思绪。/plan-add就是为了这个。赶紧把它拿出来，免得忘了。

这些还没有任何决策，但代理会保存它们，保存的同时也会先验done/计划、你为该服务发送的任何信息等等。它还会捕捉周围环境的快照（客服很擅长观察和发现你甚至不知道的事情）。

现在说到关键部分：当时机成熟时，你要审视草稿，并将其转化为一个代理可以实施的方案，而无需问你设计问题。这时你可能需要使用更高级的推理模型：

/plan-write investigate the service draft, I remember the service was having issues a few weeks ago. Search Slack for related messages. How did we solve it? Check channel #released, did we release any new service that might cause an increased load?

从这里开始，你实际上就是在调查问题所在。你证明原因，命名变更，并编写命令来证明它有效。如果这是一个功能，你就是在设计一个规范。

没有变化的调查会保留drafts/.未解问题也保持在那里，直到你回答。在我们这里，原因是上周的部署，变更是foo客户端的超时更紧。这就足够了，于是计划被写入next/:

drafts/
  hub-concurrent-bar.md
next/
  hub-service-500.md
open/
...

一旦你有几个，或者没有，你就可以用任何代理来调度计划。我这里总是用快速快速的方案。

因为计划已经包含了所有决策，你需要一个擅长编码和遵循计划的模型：

/plan-dispatch the plan for the service 500s

# or /plan-dispatch

计划里有它需要的一切，所以是一个隔离的云代理拥有所有信息。它还知道是否存在依赖关系，或者是否可以与其他计划并行调用，等等。

计划首先被迁移到open/然后代理开始处理它。

drafts/
  hub-concurrent-bar.md
next/
open/
  hub-service-500.md
done/
...

之后，代理工作并发起拉取请求。一个能够实现的计划next/本应以一个或多个PR结束。可以附带演示或给其他团队的笔记，但PR是产物。

你决定是否完成。代理报告其完成情况，并写入Markdown文件。合并PR后，你同步计划：

/plan-sync

它有什么作用？/plan-sync将记录的PR与已调度的计划进行核对。如果合并匹配，文件会移动到done/.如果缺了什么，它会问我。有时候我们会放弃改变。

那种情况下，我们会把它放进去discarded/.我还有一个/plan-status这给了我一份报告：哪些内容正在等待合并，哪些被阻碍，哪些草稿现在可以写，等等。

协调员

我在两家不同的公司用了几个月的计划系统，但当然可以更好。为什么？因为记账工作很多。而且有些手动流程可以自动化（比如查看PR或Slack消息等）。

所以，一旦你有了几十个计划，你就希望经纪人帮你执行。幸运的是，当我加入了Cursor我发现我们正在做一个新项目。而且我们刚刚宣布了昨天.它叫项目.

我不再用单独的代理人管理计划，而是通过协调员来管理计划。这些是Cursor引入的长期代理项目.协调员不自己写代码。它指挥那些写代码的特工。

它就像特工的管弦乐指挥。好的一点是，一个项目此外，还包含一些典型客服没有的功能。

首先，它可以在云端、本地机器或你拥有的远程机器上启动新的聊天会话。默认情况下，是一个全新的云代理，拥有自己的仓库克隆;代理会获取计划和项目上下文。

有时，有些工作需要我的本地机器。最棒的是，即使是在我的iPhone上，或者从网上进行Cursor.com，项目可以向我的MacBook派遣代理（假设你已启用）remote workers).最后，我还维护着一台大型Linux EC2服务器。

我用它来处理工作相关工作。

其次，它有一个Project Context标签，一个只属于项目的文件文件夹：

• Anotes.md档案。这是你的README.md 你的项目。但它是动态的。如果你愿意也可以编辑，但我只允许协调员写入。
• adocs/以及/media你作为人类打开的文件夹。
• 一个internal/特工的临时文件文件夹。你不能打开它。

然后还有一个User Context这是全局的，所有项目协调员都可以读取。它包括以下内容：

• preferences.md每当你创建一个新项目时，协调员都会读取这个。就像AGENTS.md但不会传递给特工。协调员在每回合开始时读取，特工无法获得。
• skills/文件夹。你可以在这里同步你的技能，这样所有特工都能访问。

第三，项目有subscriptions.协调员可以跟随拉取请求，看Slack频道，或者按计划起床。我的协调员订阅员工打开的每一个PR。CI结束或审核员留言时，协调员会醒来，阅读后如果有需要修正的话会让工作人员回来。

PR合并后，会取消订阅并更新计划。有时我会设置指标，然后确保协调员每6小时检查一次指标。

还记得开头的Slack消息吗？我说过这也可能是自动化。具体情况是：协调员监控频道，当警报进来时，频道就会运行/plan-add它本身。

它是否也能单独派遣，情况不一。有些协调员会立刻发出现成计划，有些还在等我下令。两者都行，我还没确定哪一个。

好处是notes.md项目的。你可以让你的代理自己更新，或者告诉它怎么做。就我而言，它保存了关于我计划的信息。所以每个协调员都有这些信息。

notes.md：目标、公关、公开、下一个、草稿、完成、链接、研究。

我的每个项目布局都一样，所以我能立刻知道发生了什么。我还确保项目的状态被保存，这样每一次对笔记的更改也会在同一回合提交到和计划相同的仓库里：

docs/
  billing/coordinator-notes.md
  storage/coordinator-notes.md
  fleet/coordinator-notes.md
  hub/coordinator-notes.md

这点非常重要。因为我在测试项目，第一周遇到了平台bug，大约460条消息后陷入了错误循环。我让它写一个交接，重新启动一个项目，并让新项目从仓库重建笔记。

它在一回合内又能正常工作了。

协调者之间不能互相消息，也无法读取对方的上下文（除了全局用户上下文）。所以他们在 git 里会互相留下内容：

docs/coordinator/
  preferences.md
  handoff-billing-2026-09-04.md
  plan-retro-2026-09-03-report.md
  inbox/hub.md
  inbox/billing.md

那里的每个文件都是四行开头：From,To,Date， 和Why.收件箱文件存放消息，每个协调者一个文件。消息包含一个复选框，包含日期、发件人和一两句话。

该Hub写入项目文件;项目写入hub.md;项目之间不会写入对方的文件，而是请求Hub。每个协调者在每回合开始时拉取并读取自己的文件，然后提交回复。

复古

看起来可能很多。确实很多！不过我一直在修改。有几点东西能很好地把所有内容串联起来。我有一项技能叫做/plan-retro.一旦被叫来，它会读出完成的图纸done/以及discarded/以及背后的转录。

我该怎么写？我们是不是一再误解？然后它会建议对某个技能进行具体修改。也可能建议删除某些技能，或者提出新的规则。

你不一定非得这么做，但非常有帮助。它的存在是为了闭合环节（记住反馈环?).经纪人如此强大，我们应该让他们不断提升我们的技能和系统。

好处是，这不仅仅是你添加的图纸。回顾步骤会看我作品的实际效果。然后它会建议修改让这个过程通过的技能。

光标项目后在名为园艺（gardening）下也有同样的想法：一个协调器，每当看到相同错误两次时就添加绒毛规则。复古就是这样，应用到技能上而不是代码库。

回顾

如果你看到这里，可能会问：我怎么下载这些技能？根本没有！而且我故意没有发布它们。这对我.但这可能根本不适合你。所以你可以这样做：把以下提示粘贴到你的经纪人中，让它生成技能文件。

这些文件将真正根据你的习惯被塑造：

Read https://arslan.io/2026/09/11/how-i-manage-my-agents/ in full. Then look at how I actually work before you write anything: go through my last three months of commits and pull requests, the issues or tickets I opened and closed, and, if you can reach them, the chat channels where I ask for work and report on it. 

Write down what repeats: how I phrase a task, what I check before I call something done, which mistakes I correct more than once, and where my work waits on other people. From that, create the plan skills from the post (plan-init, plan-add, plan-write, plan-dispatch, plan-status, plan-sync, plan-retro), plus a plan-spec skill that holds the folder layout and the plan file format the others read first, as skill files in my Cursor skills folder, written for my habits and not for the author's: my folder names, my commit and PR format, the checks I run, the people and systems my plans depend on. 

Keep each skill under two pages, in plain English, and name the exact commands it runs. Where my history shows I do something differently from the post, follow my history. When you are done, walk one made-up plan through the whole loop so I can see them work together, then stop. Commit nothing until I have read it.

这就是管理你的代理人的循环。总结一下：

• 计划中保留着这项工作
• 协调员负责运行
• 笔记和交接让任何一个都可以被替换
• 回溯则是根据我们的对话和过去的行为重写规则

感谢阅读，如果有任何问题请告诉我。