本文探讨了如何通过验证器让Agent持续试错，以及多Agent协作时遇到的协调和记忆问题。介绍了Git提交DAG、结构化工件和知识图谱如何解决这些问题，并指导读者在何时引入图技术。核心在于建立可测量、可回退、可复现的验证闭环，当协调和共享事实成为瓶颈时，再将提交谱系、工件与来源组织成图，从而提升系统效率与可追溯性。
一个 Agent 怎样靠验证器持续试错？
多个 Agent 同时工作后，为什么会出现协调和记忆问题？
Git 提交 DAG、结构化工件和知识图谱怎样接住这些问题？
什么时候应该加图，什么时候只需要把 Loop 做好？
图 1｜原始 PDF 首页明确写着“独立编撰、与 Karpathy 和 Anthropic 无隶属关系、未获背书”。
一个能自己跑下去的最小研究组织
Karpathy 的autoresearch把一个很小的语言模型训练环境交给 Agent。Agent 每次只改一处代码，训练五分钟，读取验证指标，效果变好就保留提交，变差就回退，然后继续下一轮。
这个系统只有三个关键文件。
prepare.py固定数据准备和评估逻辑，Agent 不能改。
train.py包含模型、优化器、超参数和训练循环，是 Agent 的实验面。
program.md规定研究过程、约束、指标、日志格式和自治边界，由人持续维护。
这里最容易被忽略的地方，是人并没有退出研究。人的工作对象变了：以前直接改训练代码，现在修改的是“研究组织怎样工作”的说明书。
一个完整循环大致是：
01读取当前train.py和最近的实验历史；
02提出一个有理由的改动；
03提交候选代码；
04在固定时间预算内训练；
05读取验证指标和显存占用；
06崩溃时检查原因，能机械修复就修复，否则回退；
07指标改善就保留提交，没有改善就回到上一个有效状态；
08记录结果，不等待人工确认，继续下一轮。
它能长时间无人值守，依赖环境里的四个条件：结果可以测量，改动可以回退，反馈周期足够短，活动范围受到仓库边界限制。
这四个条件比具体模型更重要。没有验证器，Agent 只能不断生成；没有回退，失败会污染后续状态；没有时间预算，一次试验就可能耗尽资源；没有受限环境，优化目标很快会漂走。
图 2｜Loop、Swarm、DAG 与 Knowledge Graph 各自外部化不同的系统负担。
program.md才是人真正维护的程序
原资料把program.md称为“对程序进行编程”。这句话并不玄。
program.md至少要写清楚可修改文件和保护文件、指标及优化方向、每轮预算、运行命令、输出解析、崩溃处理、提交与回退规则、日志格式、人工升级条件，以及什么时候应该停止。
换成普通软件工程语言，它接近一份可执行的工作契约。Agent 负责在契约内搜索；人负责设计搜索空间、验证方法和事故边界。
这也解释了为什么好的 Agent 系统越来越像一套 Harness。模型只是其中一个组件，循环、文件系统、Git、测试、权限、日志与预算共同决定了系统能不能交付。
单个 Loop 走到哪里，会开始需要 Graph
一个 Loop 的状态很简单：当前代码、上一轮指标、一次候选改动、保留或回退的结果。
第二个、第三个 Agent 加进来以后，问题发生了变化。
几个 Agent 可能同时从同一个有效状态出发，测试不同假设；它们也可能重复已经失败的实验，或者在不同分支上重新发现相同改动。某个失败没有被合并进主分支，却仍然可能提供重要证据。
这时，一条“最终正确的主分支”已经不足以描述系统发生过什么。团队需要回答更多问题：
这个结果从哪一个状态分叉出来？
哪些实验继承了同一个改动？
哪些 Agent 独立得到相同结论？
哪些叶子节点还没有评估？
哪条路径早期进展很快，后来陷入停滞？
Git 的提交 DAG 正好提供了一种天然结构：提交是节点，父子关系是边，代码差异、假设、指标、运行时间、显存、环境和保留状态都可以挂在节点上。
资料把这一步描述为 “AgentHub”。相关仓库归属目前无法从 Karpathy 的公开 GitHub 账号核验，因此本文只把它当作一种架构草图。
这张草图包含四个可独立评估的组件：裸 Git 仓库保存提交图，数据库保存元数据，API 和 CLI 提供查询，消息板承载 Agent 之间的假设、失败和协调信息。
DAG 记得住变化，知识图谱记得住事实
提交 DAG 很擅长回答“代码怎样变成现在这样”。它不擅长表达跨仓库、跨文档、跨任务的事实。
假设一个 Agent 从事故报告里抽取供应商、组件、事件和时间，另一个 Agent 正在审查某个服务的代码，第三个 Agent 在评估修复方案。
它们需要共享的是能被检索和复核的事实。完整聊天记录反而会增加后续 Agent 的重读成本：
实体是谁；
实体之间有什么关系；
关系来自哪份文档；
谁在什么运行中写入了它；
后来有没有被纠正、合并或废弃。
知识图谱由此成为共享记忆层。它把实体保存成节点，把类型明确的关系保存成边，并给节点与边附上 provenance。
Anthropic 的公开 Knowledge Graph Cookbook 展示了一条更具体的实现路线。
第一步是抽取。模型按照结构化 Schema，从文档中提取实体以及“主语—谓词—宾语”关系。
第二步是实体消歧。不同写法可能指向同一个人或组织，字符相似度不够，需要结合描述和上下文形成候选簇，再交给模型判断。
第三步是组图。实体成为节点，关系成为带类型的边；节点保留别名、来源文档和出现次数，边保留关系类型和证据。
第四步是查询。系统先从图中取出一个有边界的子图，序列化成三元组，再让模型基于这些边回答问题并给出来源。
这种设计减轻了上下文复制。Agent 不需要把所有历史对话塞回上下文，只要读取当前任务相关的子图、摘要、提交和证据。
图 3｜Graph 把任务、工件、主张、来源、运行与评估之间的关系单独保存下来。
Anthropic 的工作流模式，怎样接上这张图
Anthropic 在《Building Effective Agents》中归纳了五种常见模式。
它们分别是 Prompt Chaining、Routing、Parallelization、Orchestrator-Workers 和 Evaluator-Optimizer。
这些模式解决的是执行结构；图解决的是共享状态和来源。
Prompt Chaining 可以在每一步开始前查询图中的约束。Routing 可以根据实体类型、关系和风险，把任务送往不同工具或模型。
Parallelization 允许多个 Worker 写入互不冲突的结果。Orchestrator-Workers 可以只读取必要的子图，不必吸收所有 Worker 的完整记录。
Evaluator-Optimizer 则能沿着边检查结论是否真的有证据支持。
当系统只有一两个短任务时，图的价值不明显。Worker 数量增加、任务跨越多个会话、同一事实需要被不同流程复用，或者结果必须可追责时，共享图才开始抵消自己的复杂度。
从 Transcript Memory 走向 Artifact Memory
很多 Agent 系统把对话当记忆。会话越长，记忆越多，看上去很自然。
问题是 Transcript 本质上是连续文本。后续 Agent 需要重新阅读、理解和判断哪些内容仍然有效。一个结论被推翻以后，旧句子仍然留在上下文里；两个实体被误合并以后，也很难定位是哪个步骤造成的。
图谱化记忆的基本单位不同。它保存的是工件和关系：
Claim：一个可检查的主张；
Source：支持或反驳主张的来源；
Artifact：代码、文档、报告或数据；
Agent / Run：谁在什么运行里生成了工件；
Evaluation：依据什么规则检查过；
Version / Commit：对象处于哪个版本；
Task：这次工作服务于什么目标。
边可以表达支持与反驳：SUPPORTS、CONTRADICTS。
也可以表达生产、评估、派生和依赖：PRODUCED、EVALUATES、DERIVED_FROM、DEPENDS_ON、SUPERSEDES。
这使系统可以回答一个生产环境很在意的问题：这份输出为什么值得相信？
答案不再是“Agent 看起来分析得不错”，而是一条可回溯路径：目标、计划、执行记录、工件、来源、评估规则和最终版本。
一条更稳妥的落地顺序
原资料给出了一条从 Loop 走向 Graph 的渐进路线。压缩后，可以分成六步。
先做一个有指标的 Loop。 选一个结果可以自动检查的任务。固定预算，保存基线，让每个改动都能保留或回退。
再给它工具。 文件、搜索、数据库和代码执行都要有类型清楚的输入输出。工具调用必须可审计，副作用必须有边界。
把计划保存成工件。 计划不只存在于模型上下文里。任务、依赖、状态和验证条件写入可版本化文件。
只在需要时增加 Worker。 每个 Worker 使用隔离目录或 worktree，输出结构化结果，避免同时修改同一份状态。
持久化每次运行。 保存输入、输出、工具调用、提交、指标、失败、模型和成本。做到这一步，系统已经拥有一个很有用的执行 DAG。
最后再建图。 当多个流程需要共享实体、主张、来源和工件时，把这些对象规范化成节点与边。图是为了接住已经出现的协调问题，不是项目启动时必须购买的复杂度。
这个顺序有意把 Graph 放在最后。一个带可靠验证器的 Loop，往往比一个没有验证器的复杂多 Agent 图更有用。
图 4｜先建立验证闭环，再增加 Worker、运行记录与共享图谱。
图工程真正难的地方在写入，不在查询
知识图谱 Demo 往往从一个漂亮查询开始。生产系统更该关心写入。
每次写入至少要满足四条不变量：
01每个主张都连接来源，或者明确标记为推断；
02每个工件都有生成它的运行和版本；
03每次评估都能找到使用的规则或量表；
04被新结论取代的对象仍然可追溯，不能直接覆盖消失。
实体消歧尤其危险。把两个不同的人合并，会让错误沿所有边扩散；把同一个人拆成多个节点，又会让证据变得破碎。
因此，消歧操作应当是可解释、可逆的。系统要保存别名、候选集合、判断理由、置信度、来源和执行这次合并的 Run。
图谱也需要版本。Agent 应在一次事务中提交候选更新，先经过 Schema、权限、来源和冲突检查，再把新节点与边写入正式状态。
怎样评估一个 Graph-grounded Agent
Agent 的回答是否正确，只是第一层。
第二层是来源完整性。每个关键结论能否找到对应边，边是否连接真实来源，引用是否支持附近的主张。
第三层是图本身的质量。实体抽取的 Precision、Recall 与 F1，关系抽取的准确率，实体消歧的合并与拆分错误，孤立节点比例，来源覆盖率，都需要单独测量。
第四层是系统行为。任务成功率、验证通过率、回退率、人工升级率、延迟、成本和失败恢复时间，决定这套架构能不能进入生产。
最有用的评估循环，仍然和最开始的autoresearch一样：生成候选，运行确定性检查和模型评审，记录失败，修正系统，再跑一遍。
Graph 没有改变 Loop 的基本规律。它只是让验证对象从“一个代码改动”扩展到“多个 Agent 共同生成的一组状态、工件和关系”。
什么时候不需要 Graph
图工程很容易成为新一轮架构冲动。下面几种情况通常不值得上图：
任务短、风险低、一次会话就结束；
一个 Agent 加一个确定性验证器已经能稳定完成；
对象和关系很少，普通数据库表更清楚；
数据来源不可靠，图只会把错误保存得更持久；
没有人负责实体 Schema、消歧规则、版本与清理；
延迟和成本预算不足以支撑抽取、消歧、检索和评估。
还要警惕另一种误区：并行 Agent 增加的是搜索宽度，未必增加判断质量。任务无法拆成独立单元时，更多 Worker 只会制造更多冲突和重复。
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2026 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
