Coding Agent 工程化深化|20260627

Loop Engineering 已经把骨架立起来了, 6 月下旬正好补上五个支撑面: 内核怎么不退化, 上下文怎么不爆账单, 信息触达怎么不断线, 测试护栏怎么自己长出来, 代码量怎么不被 AI 灌水

一、为什么再写一篇

6 月 21 日 loop_engineering_paradigm_2026 给出了"四代范式 + Loop 五构件"的全景图, 但留下了五个具体没展开的问题:

Loop 跑久了 agent 会退化, 凭什么不退化?
长上下文是 Loop 的氧气, 也是账单黑洞, 怎么压?
Loop 要触达真实世界, 那个互联网不是干净 API, 怎么连?
Loop 没人盯着, 测试是最后一道护栏, 这道护栏怎么自动建?
Agent 跑得越快越容易过度工程, 谁来管 AI 写得太多?

月下旬正好补上五个支撑面, 把它们放到 Loop 框架里串一遍, 比单独看效果好得多。

二、内核: Agent 长任务退化的工程化驯化 (ECC)

社区项目 ECC (Everything Claude Code, 209k stars) 不在做新模型, 它把 Claude Code 长任务里反复出现的三个失败模式做成了五层架构。这套设计的杠杆点比表面看更深:

退化症状	根因	ECC 的工程化解
跨会话失忆	没有持久记忆机制	Hooks 100% 触发观察 → 后台 Haiku 异步分析 → 提取本能并打信心评分
40+ 轮后"幽闭恐惧" (跳测试/用 TODO 敷衍)	上下文越长注意力越散 + 目标丢失	Rules 收窄决策空间 / Agents 拆任务 / Skills 按需加载 / Hooks 守关键节点
Code Review 编造问题	LLM 讨好倾向, 不报问题怕显得没干活	输出层四问门禁 + 12 条已知误报清单 + "零发现是合法结果"明文授权

三个工程原则可以直接搬:

给 LLM 加程序化输出门禁, 不要在 prompt 里写"请谨慎" — 写发现前必须先回答四问 (能引用确切行号? 能描述具体失败模式? 读了周围上下文? 严重等级可辩护?), 一个否就降级或删除。这是 prompt 工程到 harness 工程的差距
学习数据要默认隔离, 不要默认共享 — v2.0 全局本能会把 React 习惯污染到 Python 项目, v2.1 用 git remote URL hash 把本能默认收到项目级, 2+ 项目都验证且平均信心 ≥ 0.8 才晋升全局。绝大部分 agent 经验是上下文相关的
Hook 是确定性的, Skills 是概率性的 — v1 用 skills 观察, 触发率 50-80% 意味着 20-50% 的交互根本没看到; v2 改 PreToolUse hook, 每次工具调用 100% 触发

ECC 还有一个被忽略的杠杆: 它的 406 个 Skills 是 Claude Code / Codex / Cursor / OpenCode 等 7 个平台共用的最小可移植单元。这意味着 团队的方法论资产不会被任何一个工具锁定, 明天切平台规则和方法还在。这对企业避免 vendor lock-in 是个值得抄的设计 (见 [[ecc]])

三、上下文: 让 Loop 不被账单压垮 (Headroom)

Loop 范式有一个不能回避的代价: 跑得越久, token 烧得越凶。Anthropic 工程师承认超过 40 轮模型就开始"幽闭", 而 30 分钟间隔的 loop 一天 48 轮, 复杂任务每轮几万 token。一笔 Claude Sonnet 的 287 美元个人项目账单逼出了 Netflix 高级工程师 Tejas Chopra 的 Headroom (2000+ stars, v0.22, 已为外部用户省 70 万美元 / 2000 亿 token)。

关键发现: agent 上下文里 90% 是可压缩数据, 不是创意文本 — 冗余 JSON / API 模板 / 数据库字段重复 / 工具输出嵌套。2025 年研究: 读取用户输入约占词元消耗 76%。压缩的对象不是人写的指令, 是 agent 链路里"伪装成文本的数据"。

压缩点	工程实现	适用 Loop 场景
系统提示词里 UUID/日期导致 KV 缓存全失效	CacheAligner: 只发已输入内容中变化的部分	每轮带时间戳的循环, 直接砍掉缓存未命中成本
服务器日志 / MCP 工具输出 / DB 查询	路由识别后用 AST/JSON/DOM 压缩器精简	Loop 里读日志做 CI 巡检 / 巡查 sentry / 抓 DB 慢查询
模型偶尔需要原始细节	CCR (压缩缓存与读取): 标记位 + 本地 Redis/SQLite 反查	多模型协作、需要审计追溯原始上下文的场合

Headroom 的最大差异是 可逆压缩, 不是单向裁剪, 而是给压缩段打标记, 用 MCP 让模型按需拉回原始数据。这条设计对 Loop 落地的意义是: 上下文工程从"塞多少"转向"先用别的格式塞, 真需要再展开", 信息密度而非总量成为优化目标。

斯坦福研究和 Chroma 的 18 模型对比都指向同一结论 — Context Rot (上下文腐烂): 输入越长, 输出稳定性越差, 模型更关注开头和结尾, 中间被忽略。省 token 不只是省钱, 还能让模型表现变好 — Loop 久了不退化, 这是一个比换更大模型更便宜的解法 (见 [[headroom]])

四、触达: Loop 想接真实世界的那道墙 (Agent-Reach)

Loop 在沙箱里跑得再好, 一旦要做调研、看竞品、读社区反馈, 立刻撞上互联网的破碎现实: YouTube 字幕拿不到, Twitter/X 卡在登录态, Reddit 被 403, 小红书反爬, B站接口换了。Agent-Reach (Panniantong, 38k stars, MIT, v1.5.0) 不是再造一个浏览器, 它做了一件容易被忽视的事:

把分散工具收束成 Agent 可理解、可安装、可检测、可路由的能力层, 上游工具 (gh CLI / yt-dlp / Jina Reader / feedparser / OpenCLI / bili-cli) 不动, 只做选型、安装、体检三件事。

这套思路对企业 Agent 平台的启发是:

互联网不稳定性必须纳入产品设计 — 每个平台维护"首选 + 备选"有序列表, B站从 yt-dlp 切到 bili-cli, Twitter/X 按本地登录态走不同路径。Loop 跑一周后某个 API 失效不影响整体, 路由自动降级
不要替代上游, 做能力适配层 — 当下做 agent 工具最容易踩的坑是什么都想自己做, 自己做爬虫、清洗、平台适配, 最后变成脆弱大杂烩。Agent-Reach 的克制反而让它能长期维护
体检是 agent 工具的硬要求, 不是可选项 — agent-reach doctor 区分命令缺失 / Cookie 失效 / 平台风控 / 代理不可用 / 依赖冲突 / 路线失效。Loop 跑不动时 agent 不能盲目重试, 必须能自检并解释故障

把这套放进 Loop 五构件 → 它就是 Connectors 层的可靠性补丁: MCP 把工具暴露给 agent, Agent-Reach 解决暴露之后这些工具怎么不在风控变化中失效。Loop 范式 [[loop_engineering_paradigm_2026]] 的"连接"拼图, 真要落地必须有这一层 (见 [[agent-reach]])

五、护栏: Loop 没人盯着, 测试自己长出来 (小红书 QECon)

Loop 跑得越快, 测试越是最后一道护栏。小红书质效研发部的 Agent 驱动 E2E 测试方案给出了一套与众不同的解法 — 不走 MCP 封装路线, 让 Agent 直接对接业务接口, 自主推导调用链。

端到端测试的橄榄型困境: 单元/接口测试自动化做得好, E2E 因跨域 + 长链路 + 组合爆炸长期停在 20% 覆盖率, 工程化"原子能力 + 流程编排"方案根本矛盾是 人工预制是静态有限的, 业务变化是动态无穷的。

小红书的关键设计四件套对 Loop 都有直接借鉴价值:

设计	解决什么	给 Loop 的启示
逆向链式推导	从测试目标反向倒推依赖, 直到所有入参有来源	Loop 的目标退出条件不是只验证最终结果, 而是先生成依赖树再反转排序执行
知识库渐进式加载	否决 RAG (语义检索切片污染), 改按子域目录树渐进加载	项目规范这种"结构固定、有限边界"的知识不要硬上 RAG, 渐进式加载噪声更低
Debug-first	不让 agent 凭文档猜参数, 先用 CLI 探测真实 I/O 再写脚本	Loop 第一次跑陌生工具时, 先 dry-run / 抓真实返回, 再正式执行, 一次成功率大幅提升
双层经验沉淀	工具级 (调试发现的坑写回 toolPrompt) + 链路级 (成功链路生成脚本入向量库)	这是 Loop 自我进化的飞轮 — 用得越多沉淀越多, 召回命中率越高, 执行越快

Plan-and-Execute × ReAct 混合思考模式 直接对应 Loop 五构件里的 maker/checker 分离: 宏观规划保证方向不跑偏, 微观 ReAct 保证执行有韧性。Loop 设计停止条件 (/goal) 时, 应当借鉴这个分层 — 全局目标用 Plan, 单步重试用 ReAct, 而不是混在一起。

数据构造从天级压到秒级 (脚本沉淀后 RAG 命中) 的飞轮设计, 是平台研发部跨域测试 (BFF + 多个 gRPC + DB) 可以直接复用的范式 (见 [[xiaohongshu-qecon-agent-e2e-test]])

六、约束: 谁来管 AI 写得太多 (Ponytail)

Loop + 强大模型的一个反直觉副作用: 代码量爆炸。同样一个小需求, 一不小心就几十上百行抽象封装, 评审和维护成本被反向抬高。Ponytail (DietrichGebert 开源) 把"极度懒惰的资深工程师"的代码品味做成了规则集, 注入 7 个主流 AI Coding Agent (Claude Code / Codex / Copilot CLI / Gemini / OpenCode / Pi / Cursor 等)。

6 级懒惰阶梯, AI 写代码前按顺序自问, 找到一层够用就停:

真的需要存在吗 → 不需要就跳过 (YAGNI)
标准库提供了吗 → 用它
语言/平台原生特性有吗 → 用它
项目已有依赖能解决吗 → 用它
一行能解决吗 → 写一行
以上都不行 → 写刚好够用的最小实现

经典例子: 日期选择器 → <input type="date" />, 一行。

基准测试 (3 模型 × 5 任务, 同时跑 caveman 和无规则对照): 代码量 -80~94%, 生成速度 +3~6 倍, token 成本 -47~77%, 安全/边界检查/可访问性测试全部通过。

明确划线: 信任边界校验、数据丢失风险、安全性、可访问性永远不能偷懒 — 这条很关键, 不是无脑砍代码而是分清哪些是过度工程哪些是工程底线。这与 Loop 落地启示里 "生产发布/支付/不可逆操作绝不能让 loop 自主" 同源。

实用命令体系对评审有直接价值:

/ponytail-review — 只审查当前 diff, 给出可删/可简化清单
/ponytail-audit — 全仓库过度工程体检
/ponytail-debt — 把 ponytail: 注释汇总成技术债清单 (防止"以后重构"变成口头禅)

放进 Loop 框架: 它是 Skills 层的代码品味守卫 — Loop 自动跑 review/test/build 还不够, 还要有一道"AI 别写那么多"的元规则, 否则 Loop 越跑代码量越炸, 评审成本反吃掉效率收益 (见 [[ponytail]])

七、五个支撑面的整体图

把六篇素材按 Loop 五构件 + 一道元规则归位:

Loop 构件	6 月下旬新增工程化资产
调度 / 目标	(沿用 6.21 范式)
知识 (Skills)	ECC 自学习 + 本能信心评分 / Ponytail 代码品味规则
连接 (Connectors)	Agent-Reach 互联网能力适配层 (多后端路由 + 体检)
协作 (Sub-agents)	ECC 反幻觉门禁 (四问 + 误报清单 + 零发现合法) / 小红书 Plan-and-Execute × ReAct 分层
记忆 (上下文)	Headroom 可逆压缩 / 小红书逆向链式推导 + 渐进式加载
元规则 (元品味)	Ponytail 6 级懒惰阶梯 / ECC 默认隔离, 不默认共享

八、平台研发部的落地

Hook + Skill 双层, 不要只靠 Skill — 我们 wiki-* 系列 skills 现在依赖 LLM 自己判断触发, 漏触发可能 20-50%。引入 PreToolUse hook 做确定性观察 (任何 SQL 都走、任何 git 操作都走), 把这层数据沉淀到 spec.md 自学习池, 借鉴 ECC v2 的设计
上下文不只是塞更多, 是先压缩再塞 — Headroom 思路适用我们的 MCP 工具链, 特别是 lark-* 系列 (飞书云文档/电子表格/Base 返回的嵌套 JSON 都是高冗余目标)。Token 成本不是核心, 降低 Context Rot 让模型在长 loop 里不退化才是真价值
测试 Agent 起步选有强反馈的场景 — 直接抄小红书思路, 在我们的 BFF + gRPC 跨域场景做 Agent E2E 测试。第一步不是建框架, 是把现有 wiki-* 的接口知识 + DB 结构整成"渐进式加载知识库", Agent 自主推导依赖树
Loop 之上加 Ponytail 这道元规则 — 我们已经有 ponytail skill (@wiki/entities/ponytail) 安装在全局 opencode 配置里。下一步是把 /ponytail-review 接入代码评审流程 (与 open-code-review 互补 — 后者抓 bug, 前者抓过度工程), 跑数据看一周 PR 行数变化
互联网触达层做选型路由, 不替代上游 — 当前 raw 素材采集还是手动 webfetch, 可以借鉴 Agent-Reach 的"首选 + 备选"思路把微信公众号 / GitHub / RSS / YouTube 字幕等抓取做成统一能力, 每个源带"今天能不能用"的体检接口

Coding Agent 工程化深化|20260627