Promptware 是一种自包含的智能体单元,它将自身的指令、记忆(Memory)、工具权限(Tools)以及执行历史(Logs)以文件形式保存,并在每次运行结束后自主迭代和修订自身的指令与记忆。在 Ivy Tendril 中,从拟定执行计划到发起 Pull Request 的各个生命周期阶段,均由对应的 Promptware 单元独立运行。这些指令是保存在代码仓库中的版本化文件,因此可以像对待其他源代码文件一样进行代码审查、查看 diff、回滚版本以及在团队中共享。本文将深入解析 Promptware 单元的目录结构、运行循环(run loop)、7 款内置的 Promptware,以及需要重点防范的两种失效模式。
Promptware 单元的组成部分
一个 Promptware 单元本质上是一个包含四个部分的目录。每个部分各司其职。
| 组成部分 | 存储内容 | 编写与维护者 |
|---|---|---|
Program.md |
智能体在当前阶段遵循的执行指令。每次运行后由智能体自主修订,由人类开发者审查。 | 智能体与人类开发者 |
Memory/ |
关于代码库和团队规范的持久化学习记忆。每次运行后以追加方式记录。 | 智能体 |
Tools/ |
当前阶段的严格权限作用域:智能体被允许使用的终端命令、文件路径以及集成接口。 | 人类开发者 |
Logs/ |
执行历史记录:智能体读取了什么、运行了什么、修改了什么,以及得出了什么结论。 | 智能体(仅限追加) |
Program.md 是由自然语言撰写的规范,而非代码。负责计划执行的单元中的某个小节可能如下所示:
## 在发起 Pull Request 之前
- 在代码仓库根目录下执行 `pnpm lint` 和 `pnpm test`。若其中任何一项失败,切勿发起 PR。
- 代码差异(diff)必须严格限定在计划中指定的修改文件内。若确需修改其他文件,必须在 PR 描述中详细说明理由。
- 提交信息必须遵循 `type(scope): summary` 规范。
一条记忆(Memory)记录了智能体学到的非直观经验——这些信息无法直接从现有代码中推断,但对后续运行至关重要:
### 2026-08-21, 计划 #412
`src/billing/` 目录下的结算模块当前没有任何自动化测试。在对其进行重构之前,必须先补充测试用例。
`pnpm test` 会优先执行数据库迁移;在全新的检出环境中运行大约需要 4 分钟。
这两个文件在性质上有着本质区别:程序(Program)规定了应该做什么;记忆(Memory)则记录了关于本代码库的客观事实。将二者分离开来,使得审查人员能够单独接受一条新的事实,而不必被迫接受流程规程的变动,反之亦然。
运行循环
每次 Promptware 的运行均严格遵循相同的四个步骤。
- 加载程序指令:智能体读取
Program.md以及Tools/中声明的权限规则。超出权限范围的一切操作均无法被调用。 - 读取记忆上下文:智能体读取
Memory/,确保先前历次运行沉淀的事实与背景在任务开始前已进入上下文窗口。 - 执行阶段任务:智能体执行该阶段的核心工作:制定计划草稿、扩充计划、在隔离的工作树中执行代码编写,或创建 Pull Request。所有工具调用及输出结果均追加记录至
Logs/。 - 复盘反思与回写:智能体对比实际执行结果与预期设想。新提炼的事实写入
Memory/。如果某条指令出现错误、缺失或冗余,智能体会主动修订Program.md。
“行动、观察结果、修订下一步指令”这一循环正是 ReAct 论文 为推理智能体所描述的经典模式;而 Promptware 的核心演进在于:所有的修订都会写回文件中,其生命周期超越单次会话。这第四步使得系统指令随着时间推移不断进化,而非退化。同时,这一步也是最需要人类把关与监督的环节(详见下文关于风险的讨论)。
内置的 Promptware
Ivy Tendril 自带 7 款内置 Promptware,分别对应从 GitHub Issue 到 Pull Request中介绍的各个生命周期阶段。每个单元均拥有专属的 Program、Memory、Tools 权限及 Logs。
- CreatePlan:将想法、GitHub Issue 或 Bug 报告转化为计划草稿:包含目标、范围、涉及文件及验证步骤。
- ExpandPlan:为缺乏充分执行细节的草稿补充信息,例如补齐验收标准或解决未定的设计方案。
- UpdatePlan:根据开发者添加的行内批注与反馈重新编写计划草稿。
- SplitPlan:当计划范围膨胀过大时,将其拆分为多个可并行推进的子计划。
- ExecutePlan:在隔离的 git worktree 中,调度指定的编程智能体(Claude Code、Codex CLI、Copilot CLI、Gemini CLI、OpenCode 或任何 CLI 智能体)运行获批的计划。Anthropic 在其 Claude Code 最佳实践 中所强调的“使用代码库中的指令文件”,与本节关于
Program.md的论述如出一辙。 - CreatePr:当代码差异通过自动化验证与人工审查后,在 GitHub 上开启 Pull Request。
- CreateIssue:根据执行过程中发现的问题或优化建议,自动提交 GitHub Issue。
由于每个单元严格隔离,CreatePlan 积累的记忆(例如“团队要求计划中必须列出受影响的测试文件”)不会泄露给 ExecutePlan;同样,ExecutePlan 拥有的终端 Shell 执行权限也绝不会下放给 CreatePlan。Promptware 概念文档中列出了各个单元的默认配置详情。
版本化指令与两大风险
为什么仓库内的文件远胜临时 Prompt
在聊天窗口中输入的临时 Prompt 仅存在一次、仅服务于单人,会话关闭即灰飞烟灭。而提交到代码仓库中的 Program.md 具备临时 Prompt 所没有的四大核心优势:
- 审查机制(Review):对程序指令的任何修改都体现为 Pull Request 中的 diff。资深工程师可以在某条诸如“改动较小时跳过测试”的不良指令生效前直接将其否决。
- 差异追踪(Diff):当智能体的输出质量发生变化时,在 Promptware 目录执行
git log即可清晰查看改动了哪条指令以及具体的提交时间。 - 版本回滚(Rollback):一次失败或欠妥的修订只需一个 commit 即可完整撤回。
- 团队共享(Sharing):团队中的每位开发者以及每次智能体运行,都遵从完全一致的标准指令。周一某次运行提炼出的规范,周二即可无缝赋能所有人。
这与当年推动基础设施从手工配置转向代码化版本控制(IaC)的逻辑完全一致,也契合了 The Twelve-Factor App 将配置与代码严格分离的设计哲学。关于智能体工作的其他架构模式以及 Promptware 的对比,可参阅面向编程智能体的智能体编排模式。
风险 1:指令漂移(Instruction Drift)
赋予智能体修改自身指令的能力,也意味着它有可能将指令改得更糟。例如某次运行因偶发性(flaky)测试失败,智能体可能会添加“失败测试重试最多三次”的规则,从而在后续运行中掩盖真实的缺陷。两项机制有效遏制了这一问题:首先,程序本身是版本化文件,修改呈现为可视化的 diff,审查者可随时审阅或回滚;其次,Logs/ 详细记录了触发该次修订的具体运行上下文,审查者在批准变更前可充分核实其推理逻辑是否严密。
风险 2:记忆膨胀(Memory Bloat)
只增不减的记忆最终会变成只有开销而无收益的负担。一个包含 400 条记录、其中半数已经陈旧失效的文件,不仅在每次运行时白白消耗大量的 Token,还会干扰有效信息的检索。两项工程实践可保持记忆健康:其一,如上例所示为每条记录标注日期和作用域,便于快速定位陈旧内容;其二,在代码审查时同步剪枝:当某项计划触及特定模块时,审查者顺带检查相关记忆并清理已不再适用的旧结论。按计划和按任务维度的成本及 Token 追踪机制让这种膨胀无所遁形——记忆臃肿的单元会在计划规模未变的情况下出现 Token 消耗明显上升。这也正是如何衡量 AI 编程智能体的吞吐量一文主张以“每个合并的 PR 的成本”而非“每次运行的成本”作为核心衡量指标的原因。
如何开始
安装 Ivy Tendril,打开代码仓库并创建第一个计划。7 款内置的 Promptware 从首次运行起即全部就绪。
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
在 Windows 系统上,请执行 irm https://cdn.ivy.app/install-tendril.ps1 | iex。在启动执行前通读 Program.md 文件,随后像对待常规代码审查一样,审慎检查最初生成的几条 Memory 记录和 Program 修订。在完成大约十个计划后,Memory 将准确沉淀出智能体曾遇到阻碍的代码区域——而这些区域往往也是人类开发者容易踩坑的地方。Promptware 文档提供了有关内置单元的更多指引。
常见问题解答
智能体会未经确认擅自修改 Program.md 吗?
智能体会在单次运行结束后主动拟定对其 Program 的修订。但由于 Program.md 是版本化文件,该修订以标准 Git diff 的形式呈现,供您审阅、接受或回退,且触发本次修改的完整运行日志就存放在同级目录中供随时查验。
我可以编写自己的 Promptware 吗?
内置的 7 款单元覆盖了软件开发的完整生命周期。它们包含的指令程序、记忆库和工具权限均为纯文本文件,您可以随时按团队自身的工作习惯进行调整。关于最新的扩展接口与自定义选项,请查阅官方文档。
记忆与日志存储在何处?
完整存储在运行 Tendril 的本地计算机上,绝不会上传至 Ivy 公司的云端服务器。Tendril 发起的唯一网络请求仅限于与您自行配置的 LLM API 接口以及 GitHub 通信。
开始使用 Ivy Tendril
准备好体验面向开发者的并行智能体编排了吗?
- 探索代码库:查看 GitHub 上的 Ivy Tendril(开源项目)。
- 查阅文档:访问 tendril.ivy.app 阅读集成指南。
- 预约架构咨询:发送邮件至 renco@ivy.app 预约 30 分钟的技术架构沟通。