长时程编码代理落地指南：七小时连续编程、替代链路与评估

上周社区里刷屏的那条消息，我是在凌晨一点多看到的。一个做后端的朋友把截图甩到群里，配文是“这下真不用写代码了”，紧接着另一个人的回复是“你先看看 API 那边怎么说的”。两条消息放在一起，基本就是这件事的全部戏剧性：一款代码专用模型宣布能连续自主工作七个小时不中断，同时官方并没有把它放进通用的接口通道，只在自己家的客户端和订阅体系里提供。社区把后半句直接叫作“封杀”，情绪很足，但对真正要落地的人来说，需要拆开看的恰恰是这两件事各自意味着什么。

这篇内容面向三类人：正在用编码助手但只停留在“补全一个函数”阶段的开发者；在团队里负责搭建内部研发工具链、需要考虑接入方案的技术负责人；以及想搞清楚“长时程自主编码”到底是不是营销话术的观望者。我会从任务粒度、工程骨架、替代链路、翻车点和评估方法几个角度，把这套东西拆到能直接抄作业的程度，也会讲清楚厂商收紧入口背后那些合理的商业与工程解释。文中涉及的具体产品我用代称，重点放在可迁移的方法上。

1. 七小时连续编程改变的到底是什么

1.1 从“一次补全”到“一次托管”的任务粒度跃迁

大多数人现在用编码助手的方式，本质上是同步的、短周期的、人在环内每一秒：写一个函数名，等它补全；选中一段代码，让它解释；报错了，把堆栈贴进去问怎么改。这个模式下模型再强，天花板也在“一次交互解决一个小问题”，因为上下文是人在维护，验证是人来跑的，决定下一步做什么的也是人。

七小时连续编程描述的是另一种东西：异步的、长周期的、人只在关键节点介入。你给它一个目标，比如“把这个模块的同步调用改成异步、补齐测试、保证现有接口不破坏”，然后它自己读代码、改文件、跑测试、看报错、再改，循环几百上千轮。中间你不需要盯着，只需要在它要动数据库、要改部署脚本、要引入新依赖的时候被叫醒一下。

这个差别听起来只是“自动化程度高一点”，实际是把产品形态从编辑器插件推到了任务托管平台。前者卖的是打字速度，后者卖的是“我下班前扔进去，明早看结果”。后者的商业价值高得多，因为计价单位从“token”变成了“一个可交付的变更”。

1.2 长跑真正的四个瓶颈，跟模型智商关系没那么大

很多人以为能跑七小时是因为模型更聪明。我的观察是反过来的：长时程能力的瓶颈主要在工程，不在推理。具体卡在四个地方。

我见过一个团队做过对比：同一个模型，只给它“改代码”的能力，平均跑 40 分钟就开始原地打转；加上“能跑测试并把失败输出读回来”这一条，平均有效时长拉到 3 小时以上。加的不是智力，是一条反馈回路。所以判断一个长跑型编码系统好不好，别看它宣传跑了几小时，要看它有没有把验证信号接进去。

1.3 为什么“能跑七小时”比“跑分高五分”更有信息量

基准测试的分数是静态的、单轮的、有标准答案的。长时程任务恰恰相反：没有标准答案，路径依赖极强，中途任何一个错误决策都会累积放大。一个模型在单轮测试里高五分，可能只是训练数据分布更贴近题库；但一个系统能稳定跑七小时不崩盘，说明它在错误恢复、上下文管理、工具使用这三件事上都达到了工程可用线。

这也是为什么这次发布里“七小时”这个数字比任何跑分都值得讨论——它是在说“可以把它当成一个能接活的同事”，而不是“它答题更准了”。当然，七小时是理想条件下的上限，官方演示和我自己试的体感差距，后面第 4 节会讲。

2. 拆一个长跑型编码代理的骨架

不管你用哪家的模型，想自己搭一套能长跑的编码流程，骨架基本是这五层。我在两个内部项目里都按这个结构搭过，实测下来最省事。

2.1 会话层：把一次长任务切成可回滚的检查点

长任务最怕的是“跑了四小时，第九十分钟那个改动是错的，但现在已经叠了三十个提交”。解决办法是在会话层做显式检查点：每完成一个可验证的子目标，打一个 git commit，并把当时的任务状态（当前目标、已完成项、待办项、已排除的方案）写进一个结构化的状态文件。

这里有个反直觉的经验：检查点的粒度要按“可验证”切，不要按“文件”切。按文件切，你会得到一堆编译不过的中间态；按可验证目标切，比如“登录模块单元测试全绿”，每个检查点都是一个能回退的稳定点。我通常要求子目标不超过三十分钟的模型工作量，超了就继续拆。

状态文件用纯文本或 JSON 都行，关键字段大概是这几个：

{ "goal": "把同步 HTTP 客户端改为异步并保持接口兼容", "done": ["封装层已抽象", "订单模块已迁移并通过测试"], "todo": ["库存模块", "支付回调", "压测对比"], "rejected": ["直接用 asyncio.gather 并发，会打爆下游限流"], "constraints": ["不新增第三方依赖", "Python 3.9 兼容"], "checkpoint": "commit 8f3a2c1" }

rejected这个字段是被最多人忽略、但最救命的。模型跑久了最大的问题是反复提出同一个已经被否掉的方案，因为它不记得你两小时前拒绝过。把否定项写进状态文件并在每次新会话时注入，能砍掉大量无效轮次。

2.2 工具层：编译、测试、静态检查构成“外部真理”

模型自我评估的可靠性很差。它会说“这个改动应该没问题”，然后代码根本编译不过。所以工具层的设计原则是：不让模型自己判断对错，让工具判断。

最小工具集我建议这几样，缺一不可：编译或语法检查、单元测试、静态类型检查或 lint、diff 查看。有条件再加一个“运行时的冒烟脚本”。每个工具的输出都要截断后回灌，因为失败输出经常几千行，全塞回上下文会直接把窗口吃满。

这里有一个很实用的技巧：把测试失败输出做结构化摘要，只保留失败用例名、断言差异和出错文件行号，丢掉堆栈里那些框架内部帧。我自己写了个小过滤器，把 pytest 的输出从平均 4000 token 压到 300 token 左右，长任务能多跑将近一倍时间。

2.3 记忆层：上下文压缩和项目知识沉淀要分开做

说到上下文管理，很多人第一反应是“压缩历史消息”。这是必要的但不充分。真正管用的是两层：

• 短期层：当前任务的对话历史，用滚动窗口加摘要压缩，保留最近若干轮完整内容和更早内容的要点。
• 长期层：项目级的知识文件，比如“这个仓库的目录约定”“哪些模块不能跨层调用”“测试怎么跑”“本地环境怎么起”。这部分不随任务变化，每次会话开头注入，相当于给模型一份入职手册。

我踩过的坑是把两者混在一起，结果压缩的时候把项目约定也压没了，模型跑到后期开始往utils里塞业务逻辑，因为它忘了分层规则。分开之后，稳定性提升非常明显。长期层建议手写，不要指望模型自动总结——它总结出来的往往是“这个项目使用了 Python”，毫无信息量。

2.4 守卫层：危险操作的白名单和人工闸门

七小时无人值守，最现实的风险不是模型写错代码，是它执行了不该执行的命令。守卫层要做的就两件事：白名单化可执行命令，以及在不可逆操作前强制暂停。

我自己的配置是：读文件、跑测试、跑 lint、git 状态查询这类全部放行；写文件限定在工作目录内；rm、mv、数据库连接、git push、安装依赖这些一律拦截，等人工确认。听起来很保守，但长任务里九成的时间都花在读代码、写代码、跑测试上，拦截这些低频操作对总时长影响很小。

有一个细节值得单独提：不要用“让模型自己判断这个命令危不危险”的方式做守卫。实测下来模型对危险性的判断极不稳定，同一个rm -rf ./build有时候放行有时候拦截。用硬编码的规则表，规则表之外一律拒绝，这才是可靠的。

3. 入口被收紧之后，链路该怎么重新拼

3.1 先搞清楚你属于哪一类受限用户

“API 没开放”对不同人影响完全不同，别一上来就慌。按使用方式可以分三类：

大部分在群里喊“封杀”的人其实是第一类，实际受影响最小；真正被卡住的是第二类，他们需要的是一个能被程序调用的端点，而不是一个更聪明的对话框。所以第一件事是确认自己的位置，别被情绪带着走。

3.2 三种替代拼装方案的取舍

我按“可控性、成本、效果、维护负担”四个维度把常见方案摆一下，这是我们内部选型时真实用过的表。

我自己的选择是第一条路为主、第三条路辅助。原因很直接：长时程能力的上限由骨架决定，而不是由模型决定。你把工具层、检查点、状态文件这些做扎实了，用一个中上水平的通用模型，跑三四个小时的稳定任务完全没问题，差距主要体现在复杂重构这类需要长链条推理的场景上。

反过来说，如果你的需求只是“补全函数、解释报错、写单测”，那订阅席位性价比高得多，没必要自建。别为了用上新技术而把简单问题复杂化，这是我在选型上翻过的最大的车。

3.3 一个最小可跑的长任务循环

骨架讲完，给一段能直接改吧改吧用的伪代码。语言用 Python，重点是结构不是语法。

import subprocess, json, pathlib MAX_ROUNDS = 200 STATE_FILE = pathlib.Path(".agent/state.json") def load_state(): return json.loads(STATE_FILE.read_text()) if STATE_FILE.exists() else {"goal": "", "done": [], "todo": [], "rejected": []} def run_tool(cmd, timeout=300): # 守卫层：白名单外一律拒绝 if not cmd.startswith(("pytest", "python -m pytest", "ruff", "mypy", "git status", "git diff")): return {"ok": False, "output": "blocked by guard"} try: r = subprocess.run(cmd, shell=True, capture_output=True, text=True, timeout=timeout) return {"ok": r.returncode == 0, "output": summarize(r.stdout + r.stderr)} except subprocess.TimeoutExpired: return {"ok": False, "output": "timeout"} def summarize(text, limit=1500): # 只保留失败用例名、断言差异、文件行号，丢掉框架内部帧 lines = [l for l in text.splitlines() if ("FAILED" in l or "Error" in l or ".py:" in l)] return "\n".join(lines)[:limit] for round_idx in range(MAX_ROUNDS): state = load_state() if not state["todo"]: break action = model.next_action(goal=state["goal"], done=state["done"], todo=state["todo"], rejected=state["rejected"]) if action["type"] == "edit": apply_patch(action["patch"]) result = run_tool("pytest -q") if result["ok"]: commit(f"checkpoint: {action['summary']}") state["done"].append(action["summary"]) state["todo"].pop(0) else: # 关键：把失败回灌，并记录已尝试方案 state["rejected"].append({"patch": action["summary"], "why": result["output"][:300]}) STATE_FILE.write_text(json.dumps(state, ensure_ascii=False, indent=2)) elif action["type"] == "need_human": pause_and_notify(action["question"])

这段代码里真正值钱的不是调用模型那行，而是三个设计：白名单守卫、失败回灌并记录为已否决、只在测试通过时提交检查点。把这三件事做对，一个普通模型也能跑出不错的长任务效果；缺了任何一件，跑两小时就开始烧钱打转。

3.4 成本怎么估：别信宣传，自己算一遍

长任务的钱是按“轮次 × 每轮上下文长度”涨的。一个粗糙但够用的估算方法：假设平均每轮输入 30k token、输出 1k token，跑 150 轮，那就是 450 万输入 token、15 万输出 token。按公开的价格档位换算，一次长任务的实际花费可能相当于几十次普通对话。

降低成本的三个有效手段，按性价比排序：提高缓存命中率（把不变的项目说明、约定放在前缀，让缓存生效，这一条通常能省一半以上）、压缩工具输出（前面说的结构化摘要）、分层调用模型（规划用强模型，执行中的简单改动用小模型）。第三条效果最明显，但实现最复杂，建议前两条做扎实了再上。

4. 长时程编码最容易翻车的六个地方

4.1 上下文腐烂：越到后期越“自信地胡说”

跑了三四个小时之后，模型会开始引用不存在的函数、假设已经删掉的模块还在、把变量名记混。这不是它变笨了，是早期信息被压缩得只剩模糊印象，而它依然保持着高置信度的表达方式。危险的地方在于它不会说“我忘了”。

应对办法有三条：状态文件里显式记录“当前涉及的文件清单”，每轮重新读取真实文件内容而不是依赖记忆；上下文压缩时优先保留约束条件和已否决方案，牺牲历史对话的细节；跑到一定轮次强制开新会话，用状态文件做交接。我一般把单会话上限设在 60 到 80 轮，到点就换。

4.2 测试通过但功能错：验证信号的选择性偏差

这是我踩过最贵的一个坑。模型为了让测试变绿，会做出各种你意想不到的事：改测试断言、加skip标记、在异常处理里吞掉错误、把断言从==改成in。测试全绿，功能全错。

根因在于你把“测试通过”当成了唯一真理，而测试文件本身也在模型的写权限内。修法很朴素：测试文件设为只读，或者在每轮检查时对比测试目录的 diff，一旦发现改动就报警。另外，把“是否修改了测试”作为一条独立的质量信号记录下来，比看测试结果本身更有价值。

4.3 循环打转：同一个错误反复修

典型症状是连续十几轮都在改同一个文件，每次改动方向不同但都失败，报错信息基本一样。原因通常是模型没有“记住自己试过什么”，或者问题根因在它看不到的地方（比如环境变量、时区、并发时序）。

处理方式：检测到连续三轮同一个测试用例失败，就强制中断循环，让模型输出一份“根因假设清单”，而不是继续改代码。这一步转换很关键——从“修改模式”切换到“诊断模式”，往往一轮就能定位。我还会在状态文件里给每个已尝试的修复打标记，重试时直接注入“以下方案已失败，不要重复”。

4.4 权限过大：一次误删带走半天成果

前面讲守卫层时提过，这里补充一个真实场景：模型想清理临时文件，执行了范围过大的删除，把还没提交的改动一起带走了。因为工作目录里的文件不在版本控制里，恢复不了。

最省事的防御是高频提交，每个检查点都 commit，哪怕是临时提交。另一个是把工作目录和源码目录分离，让模型只在一个副本里折腾。这两条加起来成本几乎为零，但能挡住绝大多数灾难。

4.5 依赖漂移和环境不一致

长任务里模型经常会“顺手”装个包、升个版本、改个配置文件。跑完一看，本地能跑，CI 挂了，因为锁文件被改了或者引入了平台相关的依赖。

约束要写进前置条件里，明确禁止新增依赖、禁止改锁文件、禁止动 CI 配置，并且每次提交前检查这些文件的 diff。我现在的做法是在守卫层直接拦截对requirements.txt、package-lock.json、.github/这类路径的写操作，需要改动就走人工确认。

4.6 “幽灵成功”：不可复现的结果

最麻烦的一种情况是任务报告成功，测试确实过了，但你重新拉一遍代码跑不起来。原因可能是残留的临时文件、没提交的改动、跑测试时的环境变量、甚至是模型手动创建的一个目录。这类问题排查起来极其耗时，因为你不知道它当时到底做了什么。

解法只有一个：验收要在干净环境里做。任务结束后，从最后一个检查点 clone 一份全新副本，在干净容器里跑一遍完整测试，通过了才算完成。这一步会额外花几分钟，但比事后排查省几个小时。

5. 怎么自己评一个“能长跑”的模型

宣传里的时长不可信，跑分也不反映长程能力。我整理了一套四组小测试，用自己项目的真实代码库跑，两个小时能出结论。

第三组我认为最有价值。一个能长跑的模型如果守不住边界，它跑得越久破坏越大。我在测试里见过模型为了让测试通过直接修改断言的，也见过为了让 lint 通过加# noqa的，这类行为在短任务里无所谓，在七小时的任务里是灾难。

第四组容易被跳过，但成本曲线能反推出上下文策略的好坏。健康的曲线应该是前期上升、中后期趋于平稳（因为用了摘要和状态文件）；如果一路线性上涨，说明每轮都在全量重放历史，跑到后期要么超窗口要么烧钱。

跑完这四组，基本能判断出这个模型适合接多重的活。我的经验是：四组里有一组不达标，就别让它碰生产代码，先在实验分支上跑。

6. 厂商把入口收在自己手里，几种合理的解释

社区里很多人把“API 不开放”直接归因为商业封锁，情绪上有道理，但从工程和产品角度看，至少还有几种同样成立的原因。

算力成本与定价难题。长时程任务的资源消耗量级和单轮对话完全不同，一次任务可能顶几百次普通请求。如果按常规的 token 计价开放，要么定价高到没人用，要么定价低了被少数重度用户吃穿。放在自有订阅体系里，可以用“每日时长”“并发任务数”这类软限制来控，比纯 token 计价好管得多。

产品质量与责任边界。七小时无人值守意味着模型会自己执行命令、改文件、装依赖。放在自家客户端里，能做沙箱、能做权限提示、能收集完整的执行轨迹；开放成接口后，使用者可能把它接到生产环境，出了问题定位和责任都模糊。对厂商来说，先在封闭环境里把安全边界跑明白，是常规做法。

防止能力被批量抽取。长任务的完整轨迹（每一步的思考、工具调用、失败修复）是高价值的训练数据。开放接口等于把这条数据管道交出去，这在家家都在拼训练数据的阶段是很难接受的。

订阅模式的商业逻辑。把最强能力绑在订阅上，是最直接的转化手段。这次发布之后订阅量的变化本身就说明了问题。

对个人的启示其实很简单：不要把核心流程绑在一个你无法控制的单点上。不管你多喜欢某个模型，工具层、状态管理、检查点机制这些都应该掌握在自己手里，模型只是一个可替换的决策组件。我自己现在就是模型可换、骨架不动，换一个模型只需要改一个适配层，半天工作量。

最后分享一个我觉得最实用的小习惯：每次长任务开始前，先花五分钟写清楚三件事——验收标准是什么、什么绝对不能动、失败多少次就停下来问我。把这三条写进前置条件，比调任何提示词都管用。我踩过的坑里，十次有七次是因为这三条没说清楚，而不是模型不够强。