@hanakoxbt: https://x.com/hanakoxbt/status/2091515787366306154
摘要
文章解释了如何利用循环进行自动化检查,以及通过图表优化工作流,从而减少在管理AI代理时的人工监督。
查看缓存全文
缓存时间: 2026/08/24 07:51
循环与图论:如何停止手动监督代理,仅审批最后一步(完整课程)
你检查代理执行的每一步。并非因为你愿意,而是因为没有其他机制能替代。
摆脱这种状态需要两件事,但几乎所有人只构建了其中一部分。
循环使每个工作单元无需你也能正确执行,而图则决定了哪些工作单元应该存在。
以下是关键分野、隐藏的机制,以及从审批每件事转变为只审批一件事的转折点。
循环是可失败的检查机制
剥离所有外围要素后,循环由四部分组成:生成、检查、修正、重复直至成功。
检查机制是核心。
如果离开房间时没有可让工作失败的机制,你就没有循环,只有调度器。
这听起来显而易见,但几乎没人先编写检查条件。
他们构建完工作单元后才附加审查步骤,而审查通常由另一个模型查看输出——这不过是两个乐观者的共识。
首先编写条件,并确保程序能自动评估:
绿色(通过)——测试套件退出码为0
绿色(通过)——每项主张都附来源行号
绿色(通过)——差异仅涉及计划中列出的文件
非有效检查——“输出看起来不错”
非有效检查——“模型自称确信”
非有效检查——“未触发错误”
最后一条容易误导谨慎者:无错误不等于正确。
基于此构建循环,你会得到一个系统:它自信地重复错误直至预算耗尽,且全程日志干净无误。
无人预警的上限
循环只优化单个工作单元——这是它的全部职能,且非常擅长。
但它无法决定哪些单元应存在、执行顺序,也察觉不到五个步骤中两个本可并行执行。
于是你会得到一个极优秀的代理,按错误顺序串行执行三个错误步骤。
每步都正确,结果依然缓慢且结构错误。调整循环无法解决此问题,因为问题不在任何单元内部。
这是人们责怪模型的时刻,也是上层架构开始收回成本的时刻。
图是更高层级
图是工作的拓扑结构: 决定什么运行、什么并行运行、什么等待、什么根本不运行,以及结果如何回传。
仅含两要素:节点即工作单元(一个有界任务、一个输入、一个输出),边即依赖关系(此节点的输出作为彼节点的输入)。
所有不必要等待的根源在于将“然后“误解为边。
摘要文件与检查天气之间并无依赖——天气数据不依赖摘要结果。
这是两个本应独立的节点,却被线性脚本串联,而串联顺序完全取决于你输入代码的先后。
因此对你现有流水线中的每条箭头进行验证: 下一步是否真正读取上一步的输出?
若无法指出跨越边界的变量名,则无依赖存在,等待纯属浪费。
大多数流水线有两三个此类箭头,找到它们往往是最大的单次性能优化。
全部五层详解(按重要性排序)详见: agent-layers.vercel.app
四种节点类型(其中一种不是模型)
分割器、工作节点、代码节点、门控节点——这是完整词汇表。
分割器位于前端,负责将工作切分为单元。
它比任何节点决定更多事情,因为错误的分割维度会浪费所有下游工作。
按文件夹分割仓库会导致四个审计员重复审查相同三个文件。
按影响范围分割则能让每个节点看到独特视角。
工作节点各自处理一个单元,拥有独立视角和上下文(此点常被忽视)。
若给四个审计员共享窗口,他们会趋同:第一个写出发现,其余人阅读,最终四份报告聚焦同一点。
你为四个附和的声音支付了四倍成本。
代码节点常被遗忘——涉及合并、排序、去重、比较前后输出差异。
这些都不是推理任务,每个都有唯一正确答案,只需几行代码,而调用模型会为原本确定性的步骤增加成本、延迟和波动。
若你能用“判断、决策、评估、总结“之外的动词描述转换过程,它就应是代码。
每条边都调用代理的图会为其自身连接支付租金。
循环的真实归属
一句话澄清所有混淆:循环位于节点内部,图存在于节点之间。
节点内部: 生成、检查、修正、重复直至成功。
节点之间: 分割、扇出、合并、门控、回传。第二列表中的操作无法在单个节点内实现。
因此你无需二选一。节点内部无循环的图会并行产生未验证的工作,这比串行更糟,因为错误数量倍增。
没有外层图的循环,就像队列中一个孤立的高效步骤。
两条回传路径与常被忽略的一条
没有回传路径的图只是流水线——产出结果便遗忘。
下周它会带着相同盲区从起点重新开始。
有效图包含两条回传路径,各司其职:
修正边较短——门控节点将一个单元返回生产步骤,用于修正当前运行。
学习边较长——通过的成果作为约束返回分割器,用于优化后续所有运行。
几乎所有人都只构建第一条路径,忽视第二条。典型特征是系统高效但永不进化。
学习边传递的不是输出,而是从输出中提取的约束:
已通过——utils切片首次即绿色通过
推导规则——adapters必须精确保留关键字参数
落入——分割器对后续所有切片的指令
注意“落入“位置:不是进入工作节点指令,而是进入指导工作切分的元指令。
确认的原因转化为规则,使下一次故障从此处结束点开始。
返回单元而非批次
这是回传路径最昂贵的错误,值得明确指出。
假设四个切片被移植,其中一个测试失败。若整批回传,三个正确的切片会被重写。
它们的下一版本会不同而非更好,因为它们原本就正确。
现在你需重新验证全部四个,且那三个可能因无关原因失败。
你将一个失败转化为四个不确定结果,还要为此付费。在一次运行中重复此操作将永无收敛。
表面看这像是模型反复失败,实则是回传路径在破坏正确工作。
回传单元包含四部分,各司其职:
单元——handlers切片
判定——红色
原因——test_auth_redirect失败
证据——预期302,实际200,位于handlers/auth.py:88
范围——仅修复此文件,勿触碰其他切片
范围行比看起来更重要。
无范围限制会导致回传单元膨胀: 代理打开文件,发现两个相邻问题并一并修复,使单切片修正变成四文件差异无人审查。
将尝试次数限制为三次。若单元三次修正后仍失败,问题在于生成它的工作计划,而循环无法看见计划。
基于影响范围而非置信度设置门控
多数方案构建置信度分数,设定阈值,允许超过阈值的输出通过——这是错误变量。
置信度是决策中最弱的输入,原因易被忽视:它是唯一可被模型影响的变量。
关键变量应是错误变更的代价。按错误修正成本排序工作:
可逆且局部——文案修改、测试、有覆盖的独立函数。错误合并只需回滚,此通道可优先开放。
可逆但影响广——共享工具、模式修改、多处调用的内容。需结合确定性检查与清晰轨迹门控。
难以逆转——数据迁移、删除、向生产数据写入或资金流动。此通道永不开放,与分数无关。
第三行不是极高阈值,而是永不开放的通道。区别很重要:阈值可调整,关闭的通道不会变。
开放通道内,门控节点按顺序读取证据: 先看确定性结果,再看本次运行轨迹,然后查看该节点过往回滚频率,最后才是模型自我评估。
如何应用于自身工作
选取一项重复性工作,绘制分割器、通道、合并点、一个门控、一条回传边。
首先构建门控。一旦某个环节能明确报错,所有事情都会变简单。没有门控的图只是加速产出未验证输出的方式。
接着构建通道。最后构建学习边——因为直到存在通过成果的机制,才能从已通过结果中提取约束。
将人类置于单一关键步骤:影响最大且最不可逆的环节。
审批合并结果。选择哪些修复值得发布。不审查中间输出,不确认每个步骤。
人类置于图中央会成为最慢节点,图运行速度将完全受限于人类阅读速度。
我将全部五层整合为完整课程:二十节课含模板、配置及构建顺序: agent-layers.vercel.app
三行代码涵盖全部纪律:度量路径,而非仅关注终点。
不改变后续运行的判定只是报告。
未转化为永久约束的失败,你会再次遭遇。
多数人将持续优化单个循环并称之为系统。
而绘制完整图谱的人将运行整个舰队,且永远无法理解为何他人觉得难以跟进。
如欲优先获取图层单页版摘要,请私信发送关键词“Graph“。
关注我获取更多代理内部机制解析,并订阅我的Telegram频道:
https://t.me/+75nMf005jRpjMDU1
相似文章
@hwchase17: https://x.com/hwchase17/status/2053157547985834227
文章概述了一个系统的“智能体开发生命周期”(构建、测试、部署、监控),以有效创建和管理 AI 智能体,重点介绍了 LangChain、LangGraph 和 CrewAI 等关键框架。
@jasonzhou1993: https://x.com/jasonzhou1993/status/2075179471951614381
作者分享了运行AI代理循环一个月后的实际经验,强调了循环契约、状态和日志的重要性,以使代理实现自主和可靠。
@shmidtqq: https://x.com/shmidtqq/status/2068704187492221405
一份关于AI编程代理循环工程的深入指南,解释了如何构建自动循环来重复提示代理、验证结果并避免失控成本,并通过一位工程师一个月内提交259个拉取请求的案例研究加以说明。
@ericzakariasson: https://x.com/ericzakariasson/status/2070493377267646797
一份实用指南,介绍如何为AI编码代理设置迭代循环,包括定义的停止条件、云端执行和通知渠道,以便卸载工作而无需持续监控。
@hanakoxbt: 智能体 vs 图,清晰解释!生成更多智能体虽好,但存在一个无人明说的上限:五个智能……
该推文解释了生成多个AI智能体的局限性,并介绍了图工程作为一种技术,通过战略性地管理智能体上下文和工作流程来增强覆盖范围并避免冗余。