本文探讨了如何通过验证器让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 只能不断生成没有回退失败会污染后续状态没有时间预算一次试验就可能耗尽资源没有受限环境优化目标很快会漂走。图 2Loop、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 不需要把所有历史对话塞回上下文只要读取当前任务相关的子图、摘要、提交和证据。图 3Graph 把任务、工件、主张、来源、运行与评估之间的关系单独保存下来。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 AgentAgent 的回答是否正确只是第一层。第二层是来源完整性。每个关键结论能否找到对应边边是否连接真实来源引用是否支持附近的主张。第三层是图本身的质量。实体抽取的 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大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取