李骉
“循环工程”（Loop Engineering）的转变我们正在从提示词工程 (Prompt Engineering)向Harness进行转变，同时向循环工程 (Loop Engineering)方向迈进。简单来说，Agent是干活的“人”，而Loop是让这个“人”能持续、自主干活而无需你时刻盯着的“管理系统”。在实践“循环工程”前应满足几个条件再考虑实施：并非所有任务都适合用循环处理。在构建循环前，应先评估任务是否满足以下四个条件：- 任务重复发生吗？ (例如：每周的CI失败修复)- 有自动化验收手段吗？ (例如：通过测试套件、类型检查来判断结果好坏)- Token预算扛得住吗？ (循环会反复消耗Token，需设置预算上限)- Agent有“高级工程师”的工具吗？ (能读取日志、执行命令、运行测试等)接下来，从最小可行循环（MVP）开始。首次尝试时，应构建一个包含四个基本组件的简单循环：- 触发器 (Automation): 定时或事件触发循环启动。- 技能 (Skill): 将项目上下文写入文件（如STATE.md），避免每次重复解释。- 状态文件 (State File): 记录任务进度和状态，确保循环中断后能接着运行。- 门禁 (Gate): 自动化的测试或检查，用于拦截不合格的结果。另外，checker与maker的基础分离。这是循环设计中最关键的原则：负责“写代码”的模型和负责“验收代码”的模型必须是分开的。让一个模型给自己写的代码打分，往往会“手太松”。使用一个独立的模型进行验收，才能提供真实有效的约束和反馈。最后，常见避坑指南：- 设置硬停止条件： 必须设定Token、迭代次数或时间上限，防止循环失控。- 状态必须落地： 将Agent的“记忆”写入文件，避免信息丢失。- 明确循环边界： 避免让循环处理需要人类主观判断的复杂任务（如架构设计、产品决策）。- 警惕“理解力债务”： 即使AI自动合并了代码，开发者也应定期审查，避免对系统失去理解。
发布于 北京
1
1
2
未登录
友善发言
评论
加载中
