很多人用编程 Agent 的方式还停留在聊天窗口。
流程大概是：
text
写一句提示词。
等模型生成。
看 diff。
发现问题。
再写一句提示词。
这不是错。
但它有一个明显上限：
真正费力的不是打字，而是每一轮都要判断：
text
该让 Agent 做什么？
结果有没有跑偏？
错了该怎么反馈？
这轮有没有必要继续？
成本有没有失控？
循环工程要解决的就是这件事。
它不是让 AI 无限制自动跑。
它是把“触发、执行、验证、记录、停止、预算”提前设计好，让 Agent 在边界内自己推进。
如果再往企业级大模型接入走一步，就会遇到另一个问题：
text
循环会连续调用模型。
模型会切换。
Key 会分组。
成本会累计。
失败要追踪。
日志要审计。
这时就该把 4SAPI 放进来。
不是把 4SAPI 当成一个神秘模型，而是把它当成中转模型层和企业 API 网关：
text
Loop 负责让任务一轮轮变好。
Agent 负责执行和验证。
4SAPI 负责统一模型入口、Key 权限、日志审计、模型路由和成本治理。
这一篇讲清楚：
text
什么时候值得做循环。
循环工程最小架构是什么。
14 步路线图怎么落地。
4SAPI 中转模型层应该放在哪里。
企业团队上线前要查哪些坑。
1. 先区分两种工作方式
第一种叫手动提示词。
你把 Agent 当成一个很强的助手。
你问一句，它答一句。
优点是简单。
适合：
text
一次性改文案。
临时查一个 bug。
写一段脚本。
让模型解释一段代码。
第二种叫循环系统。
你不只是写提示词，而是设计一套小流程：
text
任务从哪里来。
谁负责执行。
谁负责检查。
状态写到哪里。
失败怎么处理。
什么时候停。
每轮最多花多少钱。
适合：
text
每天扫 CI 失败。
每周升级依赖。
持续修 lint。
批量整理工单。
定时生成运营报告。
自动检查 4SAPI 调用成本。
把重复 issue 变成 PR 草稿。
差别不在模型能力。
差别在你是不是还要每轮盯着它。
2. 什么任务值得做循环
不要看到 Loop 就兴奋。
很多任务不该循环。
我建议先过这五个条件：
| 条件 | 具体判断 |
|---|
| 重复发生 | 至少每周出现一次，否则搭建成本摊不回来 |
| 结果可验 | 测试、构建、lint、类型检查、字段规则或人工验收表能判断好坏 |
| 环境可跑 | Agent 能读上下文，也能运行必要命令或访问必要工具 |
| 成本可控 | 有 token 上限、调用次数上限、时间上限或预算桶 |
| 风险可停 | 涉及合并、部署、付款、客户发送等动作时有人审 |
少一个条件，就先别上自动循环。
可以先用手动提示词。
把过程跑顺以后，再提炼成 Loop。
最危险的循环不是技术失败。
而是它看起来一直在工作，实际一直在消耗预算。
3. 循环工程的最小闭环
一个能用的循环，最少需要六个零件：
text
触发器：什么时候开始
任务卡：这一轮要做什么
执行者：哪个 Agent 或模型负责干活
验证器：用什么标准判定结果
状态文件：上一轮做到了哪里
预算闸门：最多调用多少、失败几次后停
可以画成这样：
text
触发器
↓
任务卡
↓
执行 Agent
↓
验证器
↓
状态文件
↓
继续 / 停止 / 转人工
如果进入企业环境，还要在模型调用层加一层：
text
Codex / Claude Code / n8n / Dify / 自研系统
↓
4SAPI 中转模型层
↓
Claude / GPT / Gemini / DeepSeek / 多模态模型
这层的价值不是“多套一层”。
它的价值是把模型调用变成可治理的企业级 API：
text
统一 Base URL。
统一 API Key。
按项目拆分 Key。
按团队设置额度。
按模型记录消耗。
按错误码追踪失败。
按日志复盘每轮调用。
循环越长，这层越重要。
4. 从手动提示词到循环系统的 14 步
下面这 14 步，是我建议的落地顺序。
不要跳。
跳步以后，循环很容易变成后台黑盒。
第 1 步：挑一个重复任务
先选小任务。
不要一上来就让 Agent 重写架构。
好任务长这样：
text
每晚检查失败 CI。
每周生成依赖升级 PR。
每天整理 10 条用户反馈。
每小时检查一次 4SAPI 高成本调用。
坏任务长这样：
text
优化产品体验。
重构整个系统。
自动决定是否上线。
判断客户是否值得跟进。
循环适合执行题，不适合模糊判断题。
第 2 步：写清楚目标
不要写：
要写：
text
把当前失败的 6 个测试修到 0 个失败。
本轮最多迭代 5 次。
每轮输出失败数量、修改文件和验证命令。
目标越客观，循环越稳。
第 3 步：写输入边界
告诉 Agent 它能看什么。
例如：
text
允许读取 src/、tests/、package.json、CI 日志。
不读取 .env。
不访问生产数据库。
不修改 billing 和 payment 目录。
循环跑得越久，权限边界越要早写。
第 4 步：拆执行者和验证者
不要让同一个 Agent 既写又验。
执行者负责改。
验证者负责挑错。
验证者最好是全新上下文。
它只看结果、规格和证据，不看执行者怎么说服自己的。
第 5 步：写验证信号
验证信号最好是机器可判断的。
比如：
text
pnpm test 返回 0。
pnpm lint 返回 0。
构建成功。
输出 JSON 能被 schema 校验通过。
生成文章包含标题、导语、正文、总结。
4SAPI 日志里能查到 request_id 和 model_name。
不要只写：
这些都是软判断。
软判断可以保留，但不能当唯一停止条件。
第 6 步：设停止条件
每个循环都必须知道什么时候停。
常见停止条件：
text
测试全部通过。
达到 30 条合格结果。
连续 2 轮没有新增有效结果。
调用次数达到上限。
预算达到上限。
遇到高风险文件。
需要人工确认。
没有停止条件的循环，本质上是一个会自动花钱的任务。
第 7 步：写状态文件
状态文件就是循环的记忆。
可以叫：
text
LOOP_STATE.md
STATE.md
.codex/loop-state.md
最小模板：
text
# Loop State
loop_id:
目标：
当前进度：
上一轮动作：
上一轮验证：
剩余问题：
新增规则：
下一轮只做：
是否触发人工确认：
本轮模型调用：
本轮成本：
不要只把状态留在聊天记录里。
聊天会断。
仓库里的文件不会。
第 8 步：先手动跑一轮
不要刚写完想法就上定时任务。
先手动跑一轮。
检查：
text
Agent 是否读对输入。
是否碰了不该碰的文件。
验证命令是否真的能抓住问题。
状态文件是否写得清楚。
成本是否在预期内。
手动跑不稳定，自动跑只会更不稳定。
第 9 步：沉淀成 Skill 或 Routine
如果这件事会重复，就把经验写成固定规则。
例如：
text
失败分类规则。
不能碰的目录。
常见修复路径。
验证命令。
升级到人工的条件。
这样下一轮不是从零开始。
循环真正省钱的地方，不是少写提示词，而是少重复解释背景。
第 10 步：接入 4SAPI 中转模型层
当循环开始调用多个模型，就不要到处散 Key。
建议把模型入口收敛到 4SAPI：
text
Base URL：https://4sapi.com/v1
API Key：按项目、团队、环境拆分
模型名称：从模型广场复制，保持完全一致
执行模型：性价比模型
验证模型：强推理模型
兜底模型：稳定渠道或备用模型
在自己的循环日志里增加这些字段：
text
loop_id
iteration
agent_role
model
route_reason
request_id
status
cost
stop_reason
4SAPI 负责模型调用、令牌、分组和日志。
你的业务系统负责把这些调用和具体循环关联起来。
这样后面排查才知道：
text
哪一轮开始空转。
哪个角色最贵。
哪个模型失败率高。
哪个 Key 组超预算。
哪些任务应该降级模型。
第 11 步：设置预算闸门
循环要有硬上限。
例如：
text
单轮最多 6 次模型调用。
执行者最多重试 3 次。
验证者最多运行 1 次。
单日预算超过阈值后转人工。
连续 2 次 429 或 5xx 后停止。
预算闸门不要写在脑子里。
要写在配置、状态文件或调度器里。
第 12 步：加入人工确认点
这些动作必须停下来问人：
text
合并代码。
删除文件。
改数据库结构。
修改权限。
发送客户消息。
触发生产部署。
调整 4SAPI 路由和 Key 权限。
循环可以生成建议。
但不应该绕过审批。
第 13 步：再加定时触发
等手动跑稳定了，再加定时。
常见触发方式：
text
每 30 分钟检查 PR。
每天 9 点生成成本日报。
每晚扫描 CI 失败。
每周整理依赖升级。
收到 webhook 后触发分诊。
定时不是第一步。
定时是最后的放大器。
第 14 步：复盘接受率
循环做得好不好，不看它跑了多少轮。
看这个指标：
可以拆成：
text
总调用成本 / 被接受 PR 数量。
总调用成本 / 合格报告数量。
总调用成本 / 有效工单数量。
总调用成本 / 成功修复次数。
如果接受率低于 50%，循环可能没有省 review。
它只是把 review 工作堆给你。
5. 4SAPI 中转模型层到底做什么
很多人第一次接触 4SAPI，会把它理解成：
这只是最浅的一层。
在循环工程里，4SAPI 更像企业 AI 网关。
它应该承担四件事。
第一，统一入口
工具可以很多：
text
Codex
Claude Code
n8n
Dify
Coze
OpenClaw
自研后台
但模型入口尽量统一。
否则每个工具都有自己的 Key、URL、模型名和账单，后面一定乱。
4SAPI 的位置是：
第二，模型路由
循环里不是每一步都需要最贵模型。
可以按角色路由：
| 角色 | 建议模型策略 |
|---|
| Planner | 用较强模型，负责拆任务和定边界 |
| Worker | 用性价比模型，负责执行常规改动 |
| Reviewer | 用强推理模型，负责验收和挑错 |
| Summarizer | 用低成本模型，负责整理状态 |
| Fallback | 主模型失败时切备用渠道或备用模型 |
这就是多模型统一接入的价值。
不是为了炫技。
而是把钱花在最需要判断力的地方。
第三，Key 权限管理
企业里不要一把 Key 打天下。
建议至少按这几个维度拆：
text
dev / staging / prod
内容生产 / 代码生成 / 审核验证 / 多模态
个人实验 / 团队任务 / 生产任务
低预算 / 高稳定 / 人工审批
这样出了问题能快速定位。
也能避免个人实验任务把生产预算吃掉。
第四，日志审计和成本治理
循环最怕看不到账。
你至少要能回答：
text
谁触发了这轮任务？
调用了哪个模型？
用了多少 token？
失败在哪一步？
有没有重试？
最终有没有被接受？
4SAPI 提供模型调用层的日志。
你的循环系统再补业务字段。
两边合起来，才是完整的调用追踪。
6. 4SAPI 接入循环的最小配置
如果你的工具支持 OpenAI-compatible Provider，通常可以先按这个思路配置：
text
Provider name：4SAPI
Base URL：https://4sapi.com/v1
API Key：你的 4SAPI Key
Model：从模型广场复制完整模型名称
如果某个工具要求完整接口，可以再根据工具要求使用：
text
https://4sapi.com
https://4sapi.com/v1
https://4sapi.com/v1/chat/completions
生产环境里不要只验证“能返回一句话”。
要验证：
text
流式输出是否正常。
工具调用是否正常。
长上下文是否正常。
错误码是否能被捕获。
429 是否有退避策略。
5xx 是否会切换备用模型。
日志里是否能查到本次请求。
最小环境变量可以这样设计：
text
MODEL_GATEWAY_BASE_URL=https://4sapi.com/v1
MODEL_GATEWAY_API_KEY=sk-xxxxxxxx
LOOP_PLANNER_MODEL=your-strong-model
LOOP_WORKER_MODEL=your-cost-model
LOOP_REVIEWER_MODEL=your-review-model
LOOP_MAX_ITERATIONS=5
LOOP_MAX_CALLS_PER_RUN=12
LOOP_BUDGET_BUCKET=dev-loop
模型名称不要手打。
从模型广场复制。
少一个字符，排查起来就很烦。
7. 一个可复制的循环 Prompt
下面这个模板可以直接改。
适合让 Codex、Claude Code 或其他 Agent 处理重复工程任务。
text
你是循环工程执行 Agent。
目标：
[写清楚最终要达成什么，必须可验证]
输入范围：
- 允许读取：
- 禁止读取：
- 允许修改：
- 禁止修改：
每轮动作：
1. 读取 LOOP_STATE.md，确认上轮状态。
2. 只处理本轮指定范围。
3. 修改后运行验证命令。
4. 把验证结果写回 LOOP_STATE.md。
5. 如果触发停止条件，停止并输出证据。
验证命令：
- [命令 1]
- [命令 2]
停止条件：
- 成功条件：
- 失败上限：
- 预算上限：
- 必须人工确认的情况：
模型调用要求：
- 模型入口统一走 4SAPI。
- 执行模型用于常规修改。
- 验证模型只负责检查结果。
- 每轮记录 model、role、iteration、status、cost。
最终输出：
- 本轮做了什么
- 验证证据
- 是否继续
- 下一轮只做什么
重点是“下一轮只做什么”。
很多循环跑偏，就是因为每轮都重新扩大范围。
8. 一个企业场景：每晚 CI 分诊
假设你有一个团队项目。
每天晚上 CI 可能失败。
以前流程是：
text
早上人来看。
手动点日志。
判断是不是环境问题。
分配给对应同事。
简单问题自己修。
可以改成循环：
text
触发器：每天 8:30 检查 CI。
目标：把失败分类成 env、flake、bug、dependency、infra。
执行者：读取日志，定位失败文件。
验证器：重跑失败测试或检查错误特征。
状态文件：记录已分类失败、已开 PR、已升级人工。
停止条件：全部分类完成，或遇到高风险目录。
4SAPI 中转模型层可以这样分工：
text
日志摘要：低成本模型。
根因判断：强推理模型。
修复草稿：编码模型。
PR 审查：独立 reviewer 模型。
成本记录：按 loop_id 汇总。
这样第二天早上你看到的不是一堆红色 CI。
而是一份分诊结果：
text
3 个环境问题。
2 个 flaky 测试。
1 个依赖升级导致的真实失败。
1 个已开修复 PR。
2 个需要人工确认。
这才叫循环。
不是让 Agent 跑一晚上。
而是让它带着边界、证据和成本记录跑一晚上。
9. 哪些场景不要上循环
下面几类任务，先别急。
成功标准写不出来
如果你说不清什么叫完成，Agent 更说不清。
例如：
text
让文章更有灵魂。
让产品体验更高级。
把架构变得更优雅。
这类任务适合人和模型来回讨论。
不适合无人循环。
结果不可逆
例如：
text
删除生产数据。
自动合并主分支。
自动发客户通知。
自动调整付款和权限。
可以让 Agent 生成建议。
不要让它直接执行。
没有验证器
如果没有测试、构建、规则、schema、人工审批表，就不要让循环长跑。
第二个 Agent 说“我看可以”，不等于验证。
验证要有证据。
10. 生产环境上线检查清单
把循环放到生产环境前，至少过这张表：
text
[ ] 任务是否重复发生
[ ] 成功标准是否客观
[ ] 输入范围是否清楚
[ ] 禁止范围是否清楚
[ ] 执行者和验证者是否分离
[ ] 状态文件是否持久化
[ ] 是否有最大迭代次数
[ ] 是否有单轮调用上限
[ ] 是否有预算上限
[ ] 是否有失败退避策略
[ ] 是否有人工确认点
[ ] 是否能查 4SAPI 调用日志
[ ] 是否能按 Key、模型、项目统计成本
[ ] 是否记录 request_id、model、role、iteration
[ ] 是否能关闭或暂停循环
最后一条很重要。
任何自动化系统，都必须有刹车。
11. 你真正要盯的不是 token，而是接受率
很多人谈 Loop 成本，只看 token。
但企业里更该看：
例如：
text
本周循环跑了 40 次。
花了 200 元。
开了 12 个 PR。
最终合并 8 个。
那你的核心指标不是 200 元。
而是：
再看人工 review 时间有没有下降。
如果成本下降、review 压力下降、失败可追踪，这个循环值得继续。
如果成本上升、review 队列变长、产出没人敢合，那就是失败循环。
4SAPI 的日志审计和成本统计，应该服务于这个判断。
不是只看今天花了多少钱。
而是看钱有没有换来可接受结果。
12. 最后总结
循环工程的核心不是“让 AI 自己干活”。
而是把这几件事写清楚：
text
触发条件。
任务边界。
执行角色。
验证标准。
状态记忆。
停止条件。
预算治理。
人工确认。
个人开发者可以先用最小循环。
企业团队要再加一层模型治理。
我的建议是：
text
先让一次手动运行稳定。
再沉淀成 Skill 或 Routine。
再包进 Loop。
再接入 4SAPI 做中转模型层。
最后才上定时触发。
顺序反了，就会变成一个没人理解、没人敢停、还一直花钱的系统。
一句话：
text
Prompt 解决单次输出。
Loop 解决持续迭代。
4SAPI 解决企业级 API、模型路由、日志审计和成本治理。
别只做提示词操作员。
也别迷信全自动。
更稳的路线是：搭循环，但继续做工程师。
资料与延伸阅读
- 4SAPI 官网：https://4sapi.com/
- 4SAPI 文档：https://4sapi.apifox.cn/
- 4SAPI 快速上手调用大模型 API：https://4sapi.apifox.cn/8181987m0
- 4SAPI 配置 URL 说明：https://4sapi.apifox.cn/8423139m0
