不是怀旧，也不是做数据面板。就想看看自己到底在哪些地方反复浪费时间。

猜也猜得到。真正耗人的不是某次代码改得难，是一堆小动作每天都得来一遍：

• git status、git diff、glab api、glab mr
• 查 CI 第一个挂掉的 job
• 远端主机查 SSH、PATH、Tailscale、权限
• 判断这次改动该跑哪组测试
• release / deploy 前确认 SHA、workflow、artifact
• 中途续会话重新捋 issue、branch、MR

这些事都太小了，小到你懒得专门去管。但就是因为小，才一直被放过。结果就是每天泡在这些手工胶水里。

这件事最开始的提示词其实很短：

根据我最近 codex 的项目和线程，帮我提出一些可以简化项目流程和提升效率的方法，使用子代理分头分析。

第一轮结果还是太偏最近几个项目，于是又补了一句：

不止这几个项目，扫描 ~/.codex 下所有可能的会话，分派多个 sub agent 分头分析，最后汇总。

重点不是“让模型想点优化建议”，而是把分析对象从印象里的项目，换成真实会话里的重复动作。

别急着写工具

#

我以前也这样——看见重复就觉得该写脚本。后来发现这一步常常太早。

很多重复不是命令本身重复，是判断过程重复。比如 CI 挂了，真正该固化的不是某条 gh run view，而是：

1. 先确认 run 和 head SHA
2. 找第一个挂掉的 job
3. 把有效错误截出来
4. 再判断是 workflow 的问题、依赖的问题、测试还是代码

一上来就写个大工具，容易把错误假设焊进去。轻一点的做法是先写成 skill：什么时候用、最小几步、别干什么、输出什么。

skill 不是百科全书，就是张便签——让 agent 少走一条死路。

flowchart LR
  A[Session history] --> B[Repeated friction]
  B --> C[Small skill]
  C --> D[Run on real tasks]
  D --> E[Script only when repeated]
  E --> C

最后只留了这几个：

• agent-preflight：开工前读真实 repo 状态，不靠印象
• gitlab-mr-context：用 glab api 拉 issue / MR / pipeline / notes，稳得多
• ci-first-failure：先找第一个真实失败点，再动代码
• path-verify：按改动的文件选最小验证命令
• release-deploy-preflight：部署前确认 full SHA、workflow、artifact、健康检查
• remote-health：远端主机先查 SSH、PATH、服务、锁和 Tailscale

名字都不酷，好处是不用想就知道该什么时候用。

skill 先行，脚本后补

#

还有一个教训：别一上来就给每个 skill 配脚本目录。

很多流程写个 SKILL.md 就够用了。path-verify 不是替你跑测试，是提醒你按变更路径选最小检查。让它先跟 agent 在真实任务里跑几轮，自动化等确认了再说。

脚本只干一类事：已经确定重复、确定机械、确定低风险的。

这轮我只加了一个——把 repo 里的 skills 链接到用户目录：

scripts/link-user-skills.sh

Windows 补了个 PowerShell 版：

.\scripts\link-user-skills.ps1

中间踩了个坑：软链接方向。

正确方向是 repo 放真实文件，用户目录放链接：

~/.agents/skills/glab -> /path/to/repo/skills/glab

这样 repo 能提交真实内容，本机 Codex 也能直接用。搞反了就糟了——repo 里只剩一个指向 ~/.agents 的链接，推上去别人拿不到内容，Git 还以为原文件被删了。

让它跨机器能跑

#

我常年在 macOS、Windows、远端之间切。skill 要是只在一台机器上能用，价值直接打折。

所以本机搞完之后，把 repo 同步到 my-win，Windows 上也跑同一套维护。PowerShell 版用的是 directory junction 而不是 symlink——Windows 上建 symlink 经常跟权限干架，junction 对目录链接已经够用了。

挺琐碎的一步。但不做的话，工作流沉淀很快退化成一台机器的偏方。

我现在这样想

#

做了这轮以后，几个想法慢慢变硬了。

先从会话里找重复，别从想象里设计系统。如果 git status、glab api、ssh、pnpm test 真的是高频，就从它们开刀。别为了"流程治理"编一套没人用的东西出来。

skill 要短。一个只堵一个口子。它唯一的作用是让 agent 少问一次、少查一次、少猜一次。别往里面塞百科全书。

脚本只做机械活——链接 skills、采 CI 日志、远端健康检查。产品判断、风险边界、要不要部署，该留人的确认就留，至少留个显式 preflight。

错误得回炉。软链接方向我一上来就搞反了。修完以后经验不能只停在对话窗口里，得落到脚本和 README 里，不然下次还犯。

最后留下的

#

不多：

• 几个短 skill
• 一个 Bash 链接脚本
• 一个 PowerShell 链接脚本
• 一次 Windows 同步确认
• 一条规则：repo 放真实 skill，用户目录放链接

够了。

越来越觉得，AI coding 的工作流不是造一个大平台。是把最烦人的五分钟，一遍一遍地拿掉。每次少一点，系统就轻一点。这些小规则攒够了，agent 才像是在一个配好的工程环境里干活，而不是每次从野地里重新开路。

官方配置里能调的东西有限：RUST_LOG 可以降日志级别，log_dir 只管明文 TUI log，history.max_bytes 只影响 history.jsonl。我没找到公开的 logs_2.sqlite retention、max size 或 journal mode 配置。

所以先用 SQLite 自己的机制止血。

一条 trigger 拦住新增日志

#

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

这条 trigger 的意思很直接：每次有人往 logs 表插入数据时，SQLite 直接忽略这次插入。

验证也很简单：

sqlite3 ~/.codex/logs_2.sqlite "
SELECT count(*) FROM logs;
INSERT INTO logs(ts, ts_nanos, level, target, feedback_log_body, estimated_bytes)
VALUES(strftime('%s','now'), 0, 'INFO', 'trigger_test', 'should_not_exist', 1);
SELECT count(*) FROM logs;
SELECT count(*) FROM logs WHERE target='trigger_test';
"

如果前后行数一样，并且 trigger_test 是 0，说明生效。

Windows PowerShell 版本

#

Windows 上路径通常是：

$db = Join-Path $env:USERPROFILE ".codex\logs_2.sqlite"
sqlite3 $db "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

我在远端 Windows 机器上验证过，测试 insert 前后行数不变：

trigger: block_log_inserts
before: 76387
after: 76387
trigger_test_rows: 0

恢复日志写入

#

sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_log_inserts;"

PowerShell：

$db = Join-Path $env:USERPROFILE ".codex\logs_2.sqlite"
sqlite3 $db "DROP TRIGGER IF EXISTS block_log_inserts;"

顺手压缩旧日志

#

trigger 只拦新增，不会自动缩小已经膨胀的库。退出 Codex 后再做一次 checkpoint 和 VACUUM：

sqlite3 ~/.codex/logs_2.sqlite "
PRAGMA wal_checkpoint(TRUNCATE);
DELETE FROM logs WHERE level IN ('TRACE','DEBUG');
DELETE FROM logs WHERE level = 'INFO' AND ts < strftime('%s','now','-3 days');
VACUUM;
"

如果 Codex 还开着，SQLite 可能会报 database is locked。这不是坏事，关掉 Codex 再跑。

这个办法的边界

#

它不是“修复 Codex 日志系统”，只是本机止血。

好处是不用改 Codex，不用等版本发布，也不用写守护脚本。坏处是之后 logs_2.sqlite 里不会再有新日志，本地排障能力会下降。需要排障时删掉 trigger，复现问题，再重新加回来。

长期看，正确做法还是 Codex 自己提供日志库 retention 或 max-size 配置。但在那之前，一个 SQLite trigger 已经够用了。

结果 ACE 开始不稳定了。

API key 换着花样失效，免费额度越来越难薅，几个中转服务也一个个扑街。

这也怪不了谁，毕竟本来就是 preview 功能。问题在于，编码助手的工作流已经长在语义检索上了：一天几十次 ace 调用，少了它，agent 又回到盲猜关键词的老路。

所以我换了个办法：

ferstar/fast-context

这次我没走第三方 API，而是直接逆向 Windsurf 的 SWE-grep 协议——也就是 Codex CLI 和 Windsurf IDE 自己在用的那个语义搜索后端——同时在本地加了一层 Semble 缓存做降级。

结构跟 ace-wrapper 最大的区别

#

ace-wrapper 是纯远程调用：本地只传参数，一切靠 ACE 服务。

fast-context 则是本地和远端一起上。

flowchart TB
  subgraph Input
    Q[User query]
  end

  subgraph Local
    S[Semble local prefetch
cached index + chunk search]
    A[Lexical anchors
filename / path / literal hits]
    R["Repo map
(auto-shrink when too large)"]
  end

  subgraph Remote
    WS[Windsurf SWE-grep
agentic verify + expand]
  end

  subgraph Output
    O["Candidate files
line ranges
follow-up terms
(or local chunks when remote fails)"]
  end

  Q --> S
  Q --> A
  Q --> R
  S --> WS
  A --> WS
  R --> WS
  WS -- success --> O
  WS -- auth / rate-limit / timeout --> O
  S -- fallback path --> O

流程变成：

1. 先在本地跑 Semble——缓存的索引+ chunk 搜索，毫秒级返回命中
2. 收集本地 lexical anchors——精确的文件名、路径片段、内容中的字面量匹配
3. 生成 repo map——代码树结构，太大了就自动压缩
4. 把这三样打包发给 Windsurf——Semble 的 chunk 候选当提示，lexical anchors 当锚点，repo map 给路径上下文
5. Windsurf 用 rg/readfile/tree/ls/glob 验证和扩展——agent 层的工具调用循环
6. 远端走不通时，直接返回本地 Semble 结果——不空手，不卡住

这个“不空手”其实很关键。ace-wrapper 依赖 ACE 时，服务一挂，那一轮搜索就没了。现在远端断了，本地缓存至少还能给出 chunk 级别的候选，质量差一点，但工作流不会直接卡死。

逆向 SWE-grep 的过程

#

Windsurf 的 SWE-grep 走的是 Connect-RPC + Protobuf，和典型的 REST API 完全不是一回事。

最麻烦的是 Connect 协议的帧编码。每个 RPC 帧前有个 5 字节头（1 字节 flag + 4 字节大端长度），请求和响应都这么包。协议本身还要求先发一条 Connect-Connect 帧，然后才是实际数据。

Protobuf 这边更烦。Windsurf 用的是自定义 proto schema，公开定义找不到。核心数据结构的 field numbers 只能从抓包或已知的 Wireshark 解密配置里猜——比如调用链 {1: name, 2: args, 3: id}、变量定义 {1: name, 2: type, 3: value}。猜错就整个请求失败，而且没有什么友好的报错。

整个编码器大概这样（ProtobufEncoder）：

class ProtobufEncoder:
    """手动 protobuf 编码器，完全匹配 Windsurf 的请求格式。"""
    def __init__(self) -> None:
        self.buf = bytearray()

    def _varint(self, value: int) -> bytes:
        parts: list[int] = []
        while value > 0x7F:
            parts.append((value & 0x7F) | 0x80)
            value >>= 7
        parts.append(value & 0x7F)
        return bytes(parts)

    def _tag(self, field: int, wire: int) -> bytes:
        return self._varint((field << 3) | wire)

反过来，接 Windsurf 返回的流式响应也得自己解码——拆帧、读数据、找流结束标志——最后才能拿到语义结果。比调 REST API 麻烦得多，但好处也明显：不需要任何中间服务，直接打 Windsurf 后端。

本地 Semble 缓存为什么管用

#

当初加 Semble 之前，我其实犹豫过：本地建一份索引，会不会是多此一举？

后来 benchmark 一跑，这事就没悬念了。

我拿 40 条标注查询在两个仓库上跑了对比（fastapi 和 axios），结果是：

本地 Semble 自己的召回率已经 94.6%，p50 只有 30 毫秒。Windsurf 单独跑反而有点拉——成功率只有 52.5%，剩下的不是被限流，就是报 resource_exhausted。

hybrid 模式则是把 Windsurf 放到 Semble 结果后面做验证和扩展，NDCG@10 涨到 0.890，召回率升到 97.9%。

这个结果让我确定了两件事：

• 本地缓存不是备胎，是第一道防线。它在 30 毫秒内能搞定绝大部分常见搜索，远端挂了就是降级路径，而不是直接废掉。
• Windsurf 的价值在验证，不在首轮搜索。直接让它从头搜，容易超时或被限流；给它 Semble 的 chunk 候选和精确的关键词锚点后，它只需要在已知问题上做确认，成功率明显高很多。

凭据处理也比之前复杂了

#

ace-wrapper 只需要一个 API key。fast-context 拿的是 Windsurf 的 session token，存在本地的 state.vscdb（SQLite 数据库）。

提取逻辑在 extract_key.py：

从 state.vscdb 的 ItemTable 里查 key 为 'windsurf.api_key' 的行
→ 如果有，直接返回
→ 如果没查到，再查 key 包含 'devin-session-token' 的行
→ 两种格式都能用
→ 也可以通过 WINDSURF_API_KEY 环境变量覆盖

为什么两种格式都要支持？因为 Windsurf 自己就在变。前期是标准 API key，后来改成了 devin-session-token$... 这种 session 风格的凭据。不跟着变，用户升级 IDE 后工具就废了。

现在的工作流

#

ace-wrapper 阶段，我的 AGENTS.md 长这样：

用 ace 做语义检索找候选文件 → 读文件 → 用 rg 确认精确证据

现在改成了：

用 fast-context search（默认 hybrid）找候选文件 + 行号范围
如果 hybrid 超时或无结果，试试 fast-context local-search
如果有 chunk 候选想看相关代码，用 fast-context find-related
读完文件后用 rg/ast-grep 确认精确证据

路径是多了几条，但每条都知道失败后该往哪退。

远程也搭了一套模型 fallback 链：

1. 默认用 MODEL_SWE_1_6_FAST
2. 遇到 resource_exhausted 或限流，自动降级到 MODEL_SWE_1_5
3. 还能通过 WS_FALLBACK_MODELS 自定义 fallback 顺序

Benchmark 数据

#

用 fair runner（completion-based cooldown, 40 queries）重新跑 benchmark 后，几个指标更能说明问题：

• hybrid 模式非空输出率 100%——40 条查询全部返回了有效结果
• remote 模式非空输出率只有 50%——剩下一半要么超时要么被限流
• local 模式零失败——100% 非空，p50 延迟 30 ms

这意味着，如果纯靠远程语义搜索，高峰期可能一半查询直接没响应。hybrid 模式有本地 Semble 打底后，最差也会给出本地 chunk，而不是空结果。

这次暂时不想再推翻重来的几个点

#

这次重写有几个架构选择，目前看来是对的：

1. 始终保持降级路径。任何远程依赖都得有本地回退。ACE 那次已经吃过亏了。
2. 纯 Python 更好维护。ace-wrapper 也是 Python，但这次代码量从几百行涨到了两千多行——有 protobuf 编码器、Connect 帧协议、Semble 适配层、benchmark runner——结构清楚比语言选型重要得多。Python 只是我最顺手。
3. Benchmark 要跟代码一起放。benchmarks/ 里的 40 条标注查询和 runner，跑一次就能看到各个 backend 的真实差异。没有数据支撑的优化决策，基本靠猜。
4. 凭据提取要自动适配。devin-session-token 这种变化是预料之外的，但代码结构上留了扩展点——查不到 key 就换个 pattern 再查一次，不用改主流程。

收尾

#

ace-wrapper 到现在我还在用——ACE 偶尔又能通了。但我已经不想把工作流绑死在它上面。

fast-context 的核心思路其实很简单：语义搜索先靠本地缓存托底，远端负责验证和补充。纯远程方案一旦上游抽风，就容易断绳。

如果你也踩过这个坑，代码在这：ferstar/fast-context

1. Read
2. Search
3. Change
4. Verify
5. Record

这里面最容易被低估的是 Search。

很多 agent 失败，第一步就错了：读错地方。用户说的是一个行为、一个 bug、一个跨层流程，代码里却不一定有同名函数。直接 rg login、rg upload、rg session 很快，但它只适合已知关键词。关键词都不知道时，快只会更快地跑偏。

所以我把最近常用的一小层工具开源了：

ferstar/ace-wrapper

它做的事很窄：把 Augment Context Engine 的 filesystem context search 包成一个 ace 命令，让 coding agent 可以在 shell 里先做语义检索。

为什么需要这一层

#

我关心的点很具体：把搜索动作放进 harness。

以前我经常看到这种路径：

flowchart LR
  A[User describes behavior] --> B[Agent guesses keywords]
  B --> C[Reads nearby files]
  C --> D[Edits plausible code]
  D --> E[Verification fails]
  E --> B

这个循环的问题是，失败后 agent 往往会继续围着同一批错误文件打转。它有修改能力，缺的是更好的候选文件入口。说白了，一开始摸错门，后面再努力也容易越走越偏。

ace-wrapper 想补的是这里：

flowchart LR
  A[User describes behavior] --> B[ace semantic retrieval]
  B --> C[Candidate files]
  C --> D[Read returned files]
  D --> E[rg / tests confirm evidence]
  E --> F[Small patch]
  F --> G[Verify]

这里的关键是顺序：ace 只负责找候选文件。真正的证据仍然来自读文件、精确搜索和测试。它的定位很小，就是帮 agent 少走一点冤枉路。

用法很短

#

安装：

uv tool install ace-wrapper

本地开发版：

uv tool install /path/to/ace-wrapper

查一个不知道关键词的工作流：

timeout 60s ace "user uploads an unsupported file and should see skipped-file feedback" -w /repo
rg -n "unsupported|skipped|upload|file" /repo

第一条命令回答“可能在哪些文件”。第二条命令确认“代码里到底有没有这些标识、事件、文案或测试”。

我一般会把这段规则放进项目的 AGENTS.md：

Use `timeout 60s ace "" -w ` for semantic codebase discovery.
Treat `ace` results as candidate files.
After it returns results, read the relevant files and use exact search before using them as evidence.

这几行比“多读上下文”更有用，因为它给了 agent 一个具体动作，也给了防止误判的边界。

它和 rg 怎么配合

#

ace 和 rg 更适合前后配合使用。

我特意在 README 里写了边界：ACE 只生成候选文件，证据还要从代码和测试里确认。这个边界很重要。

语义检索会返回“相近”的东西。你问一个不存在的功能，它也可能找出看起来相关的文件。如果 agent 把“有结果”理解成“功能存在”，后面就会开始编故事。只有读到实现、测试、路由、配置或调用点，结论才算站得住。

它在 Harness Engineering 里的位置

#

ace-wrapper 很小，也不该变成平台。它更像 harness 里的一个小齿轮：把“开放式找代码”这件事变成可重复、可约束的命令。

我现在更喜欢这样的项目规则：

Read -> Search -> Change -> Verify

其中 Search 要按问题类型选工具：

• 开放式、行为式、跨层链路：先 ace
• 精确标识、报错、路由、配置：用 rg
• 结构性替换：用 ast-grep
• 外部策略和行业做法：用 web research
• 旧决策、历史踩坑：用 memory

这套分工能减少 agent 的随机性。它先用语义检索缩小读文件范围，再用确定性工具确认事实，最后才动代码。顺序看起来啰嗦一点，但比一上来改错文件省事太多。

对 agent 来说，最重要的是提示方式

#

好的 ace query 要把行为讲完整，不能只堆关键词：

timeout 60s ace "frontend sends requestId to backend and starts a processing job" -w /repo
timeout 60s ace "用户拖入不支持的文件后应该显示跳过文件提示" -w /repo
timeout 60s ace "how provider config is persisted and restored after app restart" -w /repo

我会尽量包含四类信息：

• 用户动作：点击、拖拽、上传、停止生成
• 运行边界：frontend to backend、CLI handler to core service
• 预期效果：persist config、abort loop、show skipped-file feedback
• 已知字段：sessionId、requestId、files、workspace

这比只搜 upload 或 provider 稳得多。它让检索系统按行为和数据流找入口，也提醒 agent：这一步还只是语义检索，不能直接当证据。

开源它的原因

#

ace-wrapper 的代码量很小，核心就是 FileSystemContext.create(str(workspace)) 加 context.search(args.query)。我更想保存的是这几行 Python 周围的工作流约束：

1. 不知道关键词时，先语义检索
2. 一次 query 只问一个工作流
3. 把结果当候选文件
4. 读文件后再用 rg 确认精确证据
5. 没证据就不要下结论

这些规则放进工具 README、skill 和 agent prompt 后，才会稳定生效。否则每个会话都会重新靠人提醒一遍，提醒多了人也烦。

上一篇说 Harness Engineering 是给 AI 外面套工程轨道。ace-wrapper 就是其中一小段轨道：它不让 agent 更会写代码，只是让它更容易先读对地方。

从 Vibe Coding 到 Harness Engineering

前阵子我一直在看一件事：AI 到底能不能承担大部分编码工作。

现在答案基本不悬了。项目上下文、质量门禁、验证流程都跟得上时，AI 生成的代码可以稳定进入工程流程。人的时间会从“手写代码”慢慢挪到“把关”：拆需求、判断架构、整理上下文、验边界、处理失败。

最近这轮实践又往前走了一点。问题从 prompt 怎么写得更漂亮，变成了整个工作流能不能扛住长任务。这个坑我也踩了不少，尤其是早上打开电脑发现 agent 跑了一夜，但很难判断哪些改动该留的时候。

变化在哪里

#

早期的 Vibe Coding 解决的是入口问题：把需求说清楚，把项目规则写进 AGENTS.md / CLAUDE.md，再用测试、lint、review 接住模型输出。

这套方法仍然好用，只是更偏单次任务。任务一长，毛病就开始冒头：

• 上下文越塞越多，模型反而抓不到重点
• 失败后继续重试，容易把问题越修越偏
• 外部资料没查清，策略靠感觉拍脑袋
• 跑了很多轮，人醒来不知道哪些变化该保留
• 用户拒绝、权限阻断、空输出这类状态没有明确停止语义

所以我现在更愿意把这层东西叫做 Harness Engineering：给 AI 外面套一段工程轨道，让任务可执行、结果可验证、失败可恢复。名字听起来有点大，其实就是少相信一点“它会自己搞定”，多给几根护栏。

flowchart LR
  A[Task scope] --> B[Context route]
  B --> C[Agent loop]
  C --> D[Verification gate]
  D --> E[Recovery / memory]
  D -->|failed| F[Patch harness]
  F --> C

我会先管这四件事

#

第一件事是任务边界。

中型任务开始前，至少写清楚 done when、out of scope、改动面和验证命令。不需要长文档，很多时候 5 行就够。重点是让执行侧知道什么时候该停，少一点“顺手再优化一下”。

第二件事是上下文路由。

AGENTS.md 不适合写成百科全书。它更适合当索引：项目规则是什么，入口在哪里，验证命令是什么，哪些东西不能碰，下一层文档去哪读。真正的长上下文按需打开，不要整包塞回会话里。塞太满以后，模型会像我开太多浏览器标签页一样，看起来很努力，实际已经找不到重点。

第三件事是验证闭环。

我现在默认按这个顺序推进：

1. Read：读 README、AGENTS、旧文、关键实现
2. Search：用 ace、rg、ast-grep、nmem、Exa 找证据
3. Change：小范围 patch，少做顺手重构
4. Verify：先跑窄测试，再按风险扩大
5. Record：把反复踩坑写回规则、测试或 memory

这个顺序很朴素，但能压住很多失控场景。先读和先查，可以少一点模型脑补；先窄测，可以避免一口气改太大，最后谁也不知道哪一步坏了。

第四件事是失败处理。

失败后先分类型：停、重试、补 harness，还是沉淀记忆。

我以前会把很多失败都当成“再试一次”。现在会谨慎一点：能重试的问题才重试，该停的问题就得停。让 agent 带着错的前提硬冲，通常只会生成更多需要人收拾的 diff。

外部资料怎么进来

#

这轮工作流里，Exa 或类似 web search 工具的位置也更清楚了。

我一般不查宏观趋势，更常查具体工程问题：

• 超时应该设多少
• 失败要不要重试
• 默认策略怎么拆
• 主流工具给了哪些边界
• 真实 issue 里暴露了哪些失败样本

查完也不照搬。外部资料只给参照系，最后还要回到当前 repo 的约束里取舍。真正有用的结论，要落到 spec、项目规则、测试或脚本里。不然下次遇到同类问题，还是会再查一遍，等于把时间花两次。

Autoresearch 和 Ralph Loop

#

Autoresearch 更适合有明确指标的长循环。先给 agent 一个目标、一个 guard、一个验证命令，每轮只允许一个可回滚变化。这样它跑偏时，损失还能控制住。

Ralph Loop 我现在理解成“持久单负责人执行”。同一个 owner 负责推进，先有 PRD 和 test spec，再让 agent 跑长任务。它更关心长任务里的上下文、判断和验证线索，不急着把更多 agent 同时拉进来。人少一点，有时反而更容易知道责任在哪里。

这两种做法的共同点是：先定义轨道，再让 agent 跑。轨道里必须有指标、边界、验证，以及哪些改动保留、哪些改动丢弃的规则。

先抄三步就够

#

如果要把这套方法挪到团队里，我建议先别急着平台化。明天就能抄三步：

1. 每个中型任务写清 done when 和 out of scope
2. 让 agent 先列文件、证据和改动面，确认后再允许修改
3. 失败一次后先补测试、规则或脚本，再继续让 agent 跑

这三步做完，AI coding 的体验会从“能产出”往“能交付”挪一点。后面再谈 autoresearch、Ralph Loop、team worker、memory，心里也会更有底。