多个AI智能体之间上下文如何传递揭秘Antfarm的KEY变量传递与验证-重试闭环【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm当多个 AI 智能体Agent协作完成一项任务时最核心的难题是上下文传递规划者探明的仓库路径、开发者改动的分支、验证者发现的问题如何准确接力给下一个智能体Antfarm 是一款开源的多智能体工作流编排工具一句话在 OpenClaw 上搭出一支会协作的 AI 代理团队它用一个极简却优雅的机制解决了这个问题——KEY: value 变量传递 验证-重试闭环。下面带你彻底看懂这套机制。为什么多智能体协作离不开上下文传递Antfarm 的设计哲学是每个步骤都是全新会话fresh context规划者、开发者、验证者各自在独立的、干净的上下文中运行谁也不会被前面几十条消息污染。这带来两大好处不出现上下文窗口爆炸每个智能体都专注当前任务不会出现50 条消息前的幻觉状态。但新会话意味着智能体之间不能靠记忆沟通必须有一套显式的上下文传递协议。Antfarm 的答案只有 9 个字约定输出 KEY: value 键值对。核心机制KEY: value 变量如何一步步接力整个传递链路分四步全部由 src/installer/step-ops.ts 自动完成第 1 步智能体按约定格式输出每个步骤的输入模板都会要求智能体用KEY: value行回复结果。例如 feature-dev 工作流的 plan 步骤见 workflows/feature-dev/workflow.ymlReply with: STATUS: done REPO: /path/to/repo BRANCH: feature-branch-name STORIES_JSON: [ ... ]第 2 步解析并合并进运行上下文步骤完成后parseOutputKeyValues 会把输出解析成键值对键名统一转小写并支持多行值随后在 completeStep 中合并写入 SQLite 的 run 上下文——这份 JSON 就是整个工作流的公共记忆板。第 3 步用 {{占位符}} 注入下一个智能体下一步启动前resolveTemplate 会把输入模板里的{{repo}}、{{branch}}、{{build_cmd}}替换成上下文中的真实值。比如 setup 步骤的模板REPO: {{repo}} BRANCH: {{branch}}开发者智能体拿到的就是填充好的完整任务书。上下文就这样在智能体之间无缝接力全程无需人工干预。第 4 步缺少变量会提前报错而不是带病运行如果模板引用了上下文中不存在的键Antfarm 会直接把该步骤标记失败[missing: xxx]避免智能体拿着残缺信息干活——这是很多多智能体框架忽略的细节。一个真实案例feature-dev 全流程的变量接力Antfarm 内置的 feature-dev 工作流展示了完整链路plan → setup → implement → verify → test → pr → review见 workflows/feature-dev/workflow.yml。步骤产出的 KEY 变量被谁消费plan规划者repo、branch、stories_jsonsetup、implementsetup环境准备build_cmd、test_cmdimplement、verifyimplement开发者changes、testsverify、test、prtest测试者resultsprpr开发者prreview可以看到每个智能体只负责产出自己的 KEY后面所有步骤按需消费。这就是 KEY 变量传递的本质——把隐式的对话变成了显式的、可追踪的数据流。验证-重试闭环ISSUES 如何回流成 {{verify_feedback}}光有传递还不够Antfarm 的另一套精髓是验证-重试闭环开发者不能给自己作业打分验证者verifier在独立会话中逐条检查验收标准。验证通过回复STATUS: doneVERIFIED: 确认内容流程继续验证失败回复STATUS: retryISSUES: 缺失项清单。此时 handleVerifyEachCompletion 会做一件关键的事把ISSUES内容写入上下文的verify_feedback键并让 implement 步骤带着重试次数重新执行。而 implement 的输入模板里正好有VERIFY FEEDBACK (if retrying): {{verify_feedback}}于是验证者的批评被原封不动地回喂给开发者开发者在修复时就能直接看到问题清单而不是盲目重来。若重试次数超过max_retries流程会escalate_to: human升级给人处理——没有任何失败会被静默吞掉。如何为自己的工作流设计 KEY 变量与重试闭环看懂机制后你也很容易照此设计自己的工作流官方指南见 docs/creating-workflows.md。三条黄金法则每个步骤的模板里写明输出格式——告诉智能体必须返回哪些KEY: value且 KEY 用大写验证步骤永远配retry_step——用on_fail.retry_step指定回跳步骤用max_retries控制重试上限一个智能体只干一件事——传递越清晰闭环越可靠。写在最后Antfarm 证明了多智能体上下文传递不需要复杂的消息队列KEY: value 约定 集中式上下文存储 模板占位符三件套配合验证-重试闭环就能让一支 AI 智能体团队像真正的研发流水线一样可靠运转。YAML SQLite cron极简之下全是巧思。【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 多个AI智能体之间上下文如何传递？揭秘Antfarm的KEY变量传递与验证-重试闭环
多个AI智能体之间上下文如何传递揭秘Antfarm的KEY变量传递与验证-重试闭环【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm当多个 AI 智能体Agent协作完成一项任务时最核心的难题是上下文传递规划者探明的仓库路径、开发者改动的分支、验证者发现的问题如何准确接力给下一个智能体Antfarm 是一款开源的多智能体工作流编排工具一句话在 OpenClaw 上搭出一支会协作的 AI 代理团队它用一个极简却优雅的机制解决了这个问题——KEY: value 变量传递 验证-重试闭环。下面带你彻底看懂这套机制。为什么多智能体协作离不开上下文传递Antfarm 的设计哲学是每个步骤都是全新会话fresh context规划者、开发者、验证者各自在独立的、干净的上下文中运行谁也不会被前面几十条消息污染。这带来两大好处不出现上下文窗口爆炸每个智能体都专注当前任务不会出现50 条消息前的幻觉状态。但新会话意味着智能体之间不能靠记忆沟通必须有一套显式的上下文传递协议。Antfarm 的答案只有 9 个字约定输出 KEY: value 键值对。核心机制KEY: value 变量如何一步步接力整个传递链路分四步全部由 src/installer/step-ops.ts 自动完成第 1 步智能体按约定格式输出每个步骤的输入模板都会要求智能体用KEY: value行回复结果。例如 feature-dev 工作流的 plan 步骤见 workflows/feature-dev/workflow.ymlReply with: STATUS: done REPO: /path/to/repo BRANCH: feature-branch-name STORIES_JSON: [ ... ]第 2 步解析并合并进运行上下文步骤完成后parseOutputKeyValues 会把输出解析成键值对键名统一转小写并支持多行值随后在 completeStep 中合并写入 SQLite 的 run 上下文——这份 JSON 就是整个工作流的公共记忆板。第 3 步用 {{占位符}} 注入下一个智能体下一步启动前resolveTemplate 会把输入模板里的{{repo}}、{{branch}}、{{build_cmd}}替换成上下文中的真实值。比如 setup 步骤的模板REPO: {{repo}} BRANCH: {{branch}}开发者智能体拿到的就是填充好的完整任务书。上下文就这样在智能体之间无缝接力全程无需人工干预。第 4 步缺少变量会提前报错而不是带病运行如果模板引用了上下文中不存在的键Antfarm 会直接把该步骤标记失败[missing: xxx]避免智能体拿着残缺信息干活——这是很多多智能体框架忽略的细节。一个真实案例feature-dev 全流程的变量接力Antfarm 内置的 feature-dev 工作流展示了完整链路plan → setup → implement → verify → test → pr → review见 workflows/feature-dev/workflow.yml。步骤产出的 KEY 变量被谁消费plan规划者repo、branch、stories_jsonsetup、implementsetup环境准备build_cmd、test_cmdimplement、verifyimplement开发者changes、testsverify、test、prtest测试者resultsprpr开发者prreview可以看到每个智能体只负责产出自己的 KEY后面所有步骤按需消费。这就是 KEY 变量传递的本质——把隐式的对话变成了显式的、可追踪的数据流。验证-重试闭环ISSUES 如何回流成 {{verify_feedback}}光有传递还不够Antfarm 的另一套精髓是验证-重试闭环开发者不能给自己作业打分验证者verifier在独立会话中逐条检查验收标准。验证通过回复STATUS: doneVERIFIED: 确认内容流程继续验证失败回复STATUS: retryISSUES: 缺失项清单。此时 handleVerifyEachCompletion 会做一件关键的事把ISSUES内容写入上下文的verify_feedback键并让 implement 步骤带着重试次数重新执行。而 implement 的输入模板里正好有VERIFY FEEDBACK (if retrying): {{verify_feedback}}于是验证者的批评被原封不动地回喂给开发者开发者在修复时就能直接看到问题清单而不是盲目重来。若重试次数超过max_retries流程会escalate_to: human升级给人处理——没有任何失败会被静默吞掉。如何为自己的工作流设计 KEY 变量与重试闭环看懂机制后你也很容易照此设计自己的工作流官方指南见 docs/creating-workflows.md。三条黄金法则每个步骤的模板里写明输出格式——告诉智能体必须返回哪些KEY: value且 KEY 用大写验证步骤永远配retry_step——用on_fail.retry_step指定回跳步骤用max_retries控制重试上限一个智能体只干一件事——传递越清晰闭环越可靠。写在最后Antfarm 证明了多智能体上下文传递不需要复杂的消息队列KEY: value 约定 集中式上下文存储 模板占位符三件套配合验证-重试闭环就能让一支 AI 智能体团队像真正的研发流水线一样可靠运转。YAML SQLite cron极简之下全是巧思。【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考