在 Ivy Tendril 中，一个 GitHub Issue 转化为 Pull Request 经历了一条清晰严谨的阶段流水线：Issue 通过 Webhook 推送至 Inbox，智能体自动起草计划方案，开发者审核并批准计划，智能体在相互隔离的 Git worktree 中自动编码执行，自动化质量验证门禁生效，开发者审查代码 Diff，最终由智能体在 GitHub 上自动创建 Pull Request。人类工程师仅在两个关键卡点介入：审定计划与审定 Diff。其余所有繁重工作均由 AI 智能体自主完成，且支持海量工单在流水线中高并发并行流转。本文将以一个真实工单为例，完整还原其在每个生命周期阶段的流转细节。
生命周期全景概览
Ivy 将这一工程流程定义为「软件工厂」（Software Factory）：一个固定的阶段序列，智能体在其中负责具体的实现执行，而人类工程师则在预定义的控制点进行质量把关。各阶段、执行主体及流转完成条件如下表所示。更详细的技术参考可参阅生命周期文档。
| 阶段 | 参与主体 | 流转完成条件 |
|---|---|---|
| Inbox | 智能体（Webhook 触发） | Issue 的标题、正文、标签及链接已持久化归档 |
| Draft plan | 智能体（CreatePlan） | 包含明确目标、修改范围、受影响文件与验证步骤的计划草案已生成 |
| Plan review（检查点 1） | 人类工程师 | 开发者在查阅、添加批注或调整重写后，正式批准该计划 |
| Execute | 智能体（ExecutePlan） | 智能体在专属的 Worktree 中宣告任务执行完毕 |
| Verify | 智能体 | 自动化测试与代码检查（Lint）执行完毕，生成的 Diff 补丁就绪以供人工审查（质量验证门禁） |
| Diff review（检查点 2） | 人类工程师 | 开发者正式批准通过代码 Diff |
| Pull request | 智能体（CreatePr） | 通过 Pull Requests REST API 在 GitHub 上为该计划分支成功开立 PR |
| 合并与环境清理 | 人类合并 PR，智能体清理环境 | 销毁临时 Git worktree 并将本次执行积累的工程经验写入长期上下文记忆库 |
从 Issue 到批准生效的计划
1. Issue 接入
用户在代码仓库中提交了一个缺陷工单 Issue #418：“Export to CSV drops rows with commas in the description field（CSV 导出功能在描述字段包含逗号时出现丢行问题）”。GitHub 集成模块通过 Webhook 实时将其推送至 Tendril 的 Inbox 待办池。此时系统不会执行任何代码。Inbox 相当于任务准入池，由开发者决定哪些工单应被立项转化为执行计划。来自 jam.dev 的缺陷报告同样以此方式进入系统。
2. CreatePlan 起草结构化方案
开发者在列表中选中该 Issue 并点击“Create plan”。CreatePlan promptware 自动解析该 Issue 描述、提取其自身维护的仓库上下文记忆，并查阅相关代码实现，随后生成一份完整的方案草案。一份典型的草案会明确列出实现目标、预计修改的文件清单（如 src/export/csv.ts 及其单元测试文件）、技术实现路径（遵循 RFC 4180 标准为包含分隔符的字段添加转义双引号）以及验证步骤（增加一条描述中带有逗号的用例并全量回归现有的导出测试）。生成的草案会陈列在 Drafts 面板中。
3. 检查点 1：开发者评审计划
这是全程仅有的两个人工检查点中的第一个。开发者通读草案后发现了一处潜在漏洞：计划中建议仅针对 description 字段做引号转义，但实际上系统中所有自由文本字段都会遭受同样的逗号截断问题。开发者无需亲自手动重写大段方案，只需划选对应段落并添加批注：“Apply the quoting to all string columns, not just description（将转义规则应用到所有文本字段，而不仅是 description）”。UpdatePlan promptware 会根据这条批注立即全自动重构方案，并将修订后的草案重新提交给开发者复查。
若草案细节不足，开发者可一键调用 ExpandPlan 展开推演；若批注表明该工单实际上涵盖了两个独立工程目标（例如一次缺陷修复叠加一次导出模块向公共 CSV 库的架构迁移），SplitPlan 可将其无损拆解为两个相互解耦、独立推进的子计划。当方案完备且无误时，开发者点击 Approve 予以放行。自此，该计划正式确立为后续执行的法定工程契约，智能体在后续流程中无需、也不应再次模糊猜测原始 Issue 的语义。
隔离执行与质量验证
4. ExecutePlan 在隔离的 Worktree 中运行
计划获批后，Tendril 会立即为该计划检出一个专用的独立分支及对应的 Git worktree，并在该沙盒目录下启动预设的 AI 智能体。开发者可以按计划自由选用智能体：Claude Code、OpenAI Codex CLI、GitHub Copilot CLI、Google Gemini CLI、OpenCode 或其他支持命令行的自研智能体。不论选用何种底层智能体，Tendril 的编排链路完全保持统一。
采用 Git worktree 隔离机制至关重要，因为团队通常有多个计划高并发并行运转。每个计划都拥有专属的文件目录与 Git 分支，因此任何未完工的临时代码绝对不可能污染其他计划的上下文，主干分支（main）在最终代码审查通过前始终保持纯净稳定。关于此架构设计的深层原理，可参阅用于并行 AI 智能体的 Git worktrees。
智能体编码期间，Tendril 的 Jobs 界面会以毫秒级流式呈现所有终端输出与 Tool Call 工具调用轨迹：读取了哪些文件、执行了哪些 Shell 命令、运行了哪些单元测试，以及当前耗费的 Token 数量与 API 成本。工程师可以实时观察进展，也可以直接切换去评审其他计划。若开启了 Cloudflare Quick Tunnel 安全内网穿透，工程师甚至可以在手机端无缝同步查看流式日志。
5. 质量门禁自动验证
当智能体在终端中汇报任务完成时，系统会自动在当前 Worktree 环境中触发质量门禁验证：完整跑通项目测试套件（Test Suite）与静态代码风格扫描（Linter），并将变更补丁统一汇总为 Diff。验证结论在 Review 界面中通过 tests、lint、diff 三个标签页直观展示。测试失败或类型报错会在人类耗费精力审阅代码之前第一时间阻断暴露。Pro 与 Enterprise 版还支持将 CI/CD 持续集成流水线的远程测试报告回传联动。关于为何必须将验证作为硬性质量门禁而非建议性参考，可参阅AI 生成代码的质量验证门禁。
人工复审、PR 创建与环境回收
6. 检查点 2：开发者审定 Diff
这是第二个核心人工卡点。在 Review 界面中，开发者对照最初核准的计划方案以及自动化验证报表，集中审查代码 Diff。针对 Issue #418，本次 Diff 精准修改了 src/export/csv.ts，引入了合规的字段转义辅助方法，并在测试文件中新增了覆盖“逗号、双引号、字段内换行符”的三组边界用例。测试全绿，代码检查零报警。开发者正式点击批准 Diff。
如果 Diff 未能完全满足预期，开发者可拒绝放行，在计划中追加遗漏的需求说明，并指令智能体再次执行迭代。未经此步人工明确放行，任何代码绝对不会被推送到远端 GitHub。
7. CreatePr 自动提交 Pull Request
通过审查后，CreatePr promptware 会基于当前计划分支自动向 GitHub 提交规范的 Pull Request。自此，任务顺畅切入团队既有的 GitHub Code Review 与团队日常合并流水线。Tendril 的 Pull Requests 看板会自动跟踪所有由该管道衍生的活跃 PR 状态。
8. 合并后的闭环清理
当 PR 在 GitHub 上完成合并后，Tendril 会在本地自动抹除该临时 Worktree。随后，ExecutePlan promptware 会将本次开发任务中提炼出的工程要点固化入项目的全局记忆库中。例如，它会写入一条新认知：“The export module has an integration test that needs the fixtures in test/fixtures/export/; run it with pnpm test:export”。未来任何涉及该模块的新计划在启动前，都会自动检索并加载这条经验。
对于此种规模的日常缺陷工单，整条流水线仅耗费 AI 智能体数分钟的计算时间以及人类工程师两次简短的决断时间。Ivy 官方团队的实践表明，在完整保留这两道人工质量卡点的前提下，其研发团队的日常 PR 交付能力从过去的每天约 10 个大幅跃升至每天超过 100 个。
快速上手
只需安装 Tendril 客户端，绑定 GitHub 仓库集成让 Issue 自动流转至 Inbox，建议首先挑选一个典型任务让单个智能体完整跑通该流水线，随后再逐步开启大规模并行计划。
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Windows 环境下可直接通过 PowerShell 运行：irm https://cdn.ivy.app/install-tendril.ps1 | iex。基于 Functional Source License 开放源码的免费版本已完整包含全生命周期的核心编排功能。Pro 版与 Enterprise 版则进一步提供团队协同、CI 验证结果导入以及企业内网私有化托管支持。
常见问题解答
变更极小时，智能体能否自动跳过人工检查点？
绝对不能。两个人工检查点适用于系统中的任何计划。哪怕是一行代码的微小调整，也必须严格经过计划审查与 Diff 审查。改动较小的计划在实际审查中往往只需花费工程师数秒钟的时间。
当两个并行推进的计划同时修改了同一文件会怎样？
由于每个计划都在其独享的 Git worktree 与独立分支中运转，因此在编码执行阶段绝不会出现本地文件冲突。潜在的冲突会在第二个 Pull Request 执行 Rebase 或 Merge 时在 Git 层面正常暴露，并按照标准 Git 冲突解决流程予以平稳处理。按照模块合理拆解计划可大幅降低发生此类冲突的概率。
任务必须来自于 GitHub Issue 吗？
并不强制。计划的输入源可以是一个在输入框直接敲入的想法、jam.dev 提交的 Bug 报单、命令行 CLI、REST API 或来自 MCP 服务器的远程调用。GitHub Webhook 只是任务进入 Inbox 的众多标准通道之一。
开始使用 Ivy Tendril
准备好体验面向开发者的并行智能体编排了吗？
- 探索代码库：查看 GitHub 上的 Ivy Tendril（开源项目）。
- 查阅文档：访问 tendril.ivy.app 阅读集成指南。
- 预约架构咨询：发送邮件至 renco@ivy.app 预约 30 分钟的技术架构沟通。