@akshay_pachaar: Andrej Karpathy：“别让自己成为瓶颈。最大化你的杠杆效应。投入极少的令牌，却能收获巨大的成果……”

Andrej Karpathy： “别让自己成为瓶颈。最大化你的杠杆效应。投入极少的令牌，却会有大量的工作代表你完成。” 循环工程正是实现这一目标的关键。 在手动运行的会话中，你要做两件事：决定代理下一步运行什么，以及在下一步之前检查它的输出。这两者都是手动的，也是没有你时代理能走多远的限制因素。 循环工程将这两个步骤都移入系统。下图展示了围绕循环的运行结构： → 触发器决定要运行什么，无论是消息、事件还是计划，这样代理就可以在没有你的情况下启动。 → 循环是制造器，负责产生工作、思考、行动和观察，直到完成或被刹车停止。 → 一个独立的检查器对输出进行评分，因为模型自我评分只会为其已经完成的工作辩护，而不会捕捉失败之处。检查器的结果作为下一个指令返回给制造器，循环重复直到没有需要修复的内容。 → 状态保存在磁盘上，而非上下文中，因为模型会在运行之间遗忘所有内容。一个MD文件或知识图谱记录了已完成和未完成的工作，这样循环可以在几天后继续。 对于这一状态层，Zep的Graphiti是一个简洁的开源选择，它是一个时序知识图谱，可以废弃过时的事实，并通过向量、全文和图搜索在一次调用中返回上下文。 repo: http://github.com/getzep/graphiti 有两个因素决定了无人值守循环是否可靠。 退出条件必须在循环运行之前设置，而不是在运行过程中。没有停止条件的循环会消耗令牌，一旦子代理和长时间运行累积起来，成本会迅速攀升。一个清晰的退出条件类似于“所有测试通过且代码检查无误，两轮后停止。” 而且检查器只会捕获运行内部的失败。循环周围的框架——围绕模型的提示、工具和检查——随着模型的变化而在生产环境中漂移和失效。捕捉这些需要每次运行的可观测性，而不是一个绿色勾选标记。 Comet的Opik正是为这一层构建的，它是一个开源工具，可以追踪每次调用，并将失败的生产痕迹转化为回归测试，这样同样的错误就不会再发生。 repo: http://github.com/comet-ml/opik 你的工作不再是作为循环内部的操作者。而是设计无需你就能运行的机器，然后密切观察痕迹直到你足够信任它。 模型正在变成一种商品。围绕它的循环才是真正工程所在。 我写了完整的解析。文章如下引用。 敬请期待更多内容！