在 tmux 中基于 Markdown 规范运行并行编码代理
建议工作流：使用 tmux、Markdown 规范和 bash 别名运行并行编码代理。为窗口分配角色（规划者、执行者、项目经理），并通过带编号的“功能设计”（FD）文件和斜杠命令管理功能。任务：作者实施了一种并行编码工作流，使用 tmux、Markdown 功能设计（FD）规范和六个自定义斜杠命令（/fd-init、/fd-new 等）来管理代理生命周期。代理在单独的 tmux 窗口中被分配角色（规划者、执行者、项目经理），代码更改与编号的 FD 文件绑定，并在 FEATURE_INDEX.md 中跟踪。人类充当业务上下文与 FD 之间的桥梁，审查规范，在 Cursor 中添加内联注释，并在关闭任务前批准验证步骤。；工具：custom-built or unnamed agent。人工角色：原始帖子没有说明人如何参与。；局限：该系统需要手动将业务需求转换为 FD 规范，且缺乏多用户协作功能。上下文窗口压缩可能会丢失关键的规划决策，因此需要频繁检查点。作者指出 Claude Code 权限系统存在安全问题，需要采用拒绝列表方法以防止破坏性命令。这是一个个人设置，而非标准化的企业工具。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
建议工作流：使用 tmux、Markdown 规范和 bash 别名运行并行编码代理。为窗口分配角色（规划者、执行者、项目经理），并通过带编号的“功能设计”（FD）文件和斜杠命令管理功能。
工作流程
作者实施了一种并行编码工作流，使用 tmux、Markdown 功能设计（FD）规范和六个自定义斜杠命令（/fd-init、/fd-new 等）来管理代理生命周期。代理在单独的 tmux 窗口中被分配角色（规划者、执行者、项目经理），代码更改与编号的 FD 文件绑定，并在 FEATURE_INDEX.md 中跟踪。人类充当业务上下文与 FD 之间的桥梁，审查规范，在 Cursor 中添加内联注释，并在关闭任务前批准验证步骤。
原文报告的结果
作者报告能够有效地管理 4 到 8 个并行代理，在一个项目中完成了超过 300 个 FD 规范。然而，他们指出，超过 8 个代理后，认知负荷增加，决策质量下降。未提供具体的性能指标或业务成果，仅有关于工作流压力和上下文窗口限制的定性观察。
人工角色
原始帖子没有说明人如何参与。
局限
该系统需要手动将业务需求转换为 FD 规范，且缺乏多用户协作功能。上下文窗口压缩可能会丢失关键的规划决策，因此需要频繁检查点。作者指出 Claude Code 权限系统存在安全问题，需要采用拒绝列表方法以防止破坏性命令。这是一个个人设置，而非标准化的企业工具。
试一试
我想复制源中描述的并行编码代理工作流。首先，通过运行 /fd-init 在我的仓库 [replaceable: repo_url] 中初始化 FD 系统。使用 /fd-new 为 [replaceable: feature_description] 创建一个新的功能设计。我将充当规划者：审查生成的 FD-XXX.md 文件，为任何歧义添加内联 %% 注释，并确认实施计划。一旦我批准规范，在单独的 tmux 窗口中启动一个执行者代理来实施更改。确保执行者首先使用“计划模式”，然后在我审查后使用“接受编辑”。在我根据 FD 的验证步骤手动验证输出之前，不要关闭 FD 或合并更改。如果任务复杂，请使用 /fd-deep 在最终确定计划前探索替代方案。如果我的当前环境中没有 FD 模板或斜杠命令，请停止并请求澄清。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。