即刻App年轻人的同好社区
下载
Barret李靖
170关注12k被关注11夸夸
编程领域优秀贡献者
🧑💻 软件工程师 / 终身学习者 / 俩妞爸
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
🧐 AI / Cloud Native / Indie Maker
👻 小胡子哥，一个有趣的灵魂
看到很多朋友问过一个问题，为什么给我的 Claude Code 安排任务，它都不会一口气执行完，而是跑最多几十分钟就停下来，然后问我要不要继续。例如让它把项目中的单测全部补全（大概 1k 个），它跑了大概 200 个就停下来了。
cc 并不是对一句话任务抗拒，如果不理解它的执行机制，很难设计出能跑长程任务的 harness 流程。
在执行一个超大任务的时候，单 agent 的执行流程大概是这样的：1）刚开始是高效模式，指令遵循效果特别棒；2）跑了大概 80k tokens 的时候，context 开始逼近 compact 阈值；3）紧接着，对话历史被压缩为摘要，模型开始忘记刚才修复单测的细节；4）再经过一两轮 auto-compact，它甚至会开始重复检查已修复的测试，当触发 maxTurns 并且 response 没有 ToolUse 指令时，模型会退出任务，然后开始询问用户："我已经修复了约 200 个测试，要继续吗？"
如果你在当前 session，回复继续，接下来的工作，它会做的更加不符合预期，并且退出得更快。
任何试图在一个 agent session 内完成海量工作的方案，最终都会碰到 context 膨胀 → compact → 信息丢失 → 效率下降的问题。
其实优化方向也特别简单，设计一个主-子 Agent 的运行模式（任务调度器），同时将任务进度写到 file system 中（进度持久化），每个子 agent 有独立 context、独立退出逻辑，主 agent 只负责调度和进度追踪，从而绕过单一 agent 的所有瓶颈。
因此给 cc 的指令需要包含至少这三部分：
1）任务分解。不要给一个无边界的指令（如修复所有单测），而是先扫描出所有失败测试，按目录或模块分组，每组 15-30 个，作为一个独立子任务。关键是每个子任务的 prompt 必须自包含——写清楚文件路径、错误现象、期望行为，不能写"根据之前的分析来修复"，因为子 agent 看不到父 agent 的历史。
2）进度持久化。在项目根目录维护一个 progress.json，记录 completed / failed / pending 三个列表。主 agent 每轮调度前读这个文件决定下一批任务，子 agent 完成后更新对应条目。这样即使主 agent 自己被 compact，重读文件就能恢复全部状态。
3）失败策略。子 agent 报错时，如果错误可修复，用 SendMessage 继续同一个子 agent（保留错误上下文更高效）；如果方向完全错了，启动新的子 agent 避免锚定在错误路径上；多次失败则上报用户，不要无限重试烧 token。
Claude Code 其实已经内建了这套能力。最直接的方式是启用 Coordinator Mode（输入 /coordinator），主 agent 自动变成纯调度者：它不执行任何实际工具调用，只负责理解子 agent 的返回结果、合成下一步的具体指令、并行派发独立任务；而每个子 agent 会通过 AgentTool 启动，它们有独立 context。
记住一句话就行了：设计多个 agents，各司其职、快进快出，把进度交给文件系统来记忆。
cc 并不是对一句话任务抗拒，如果不理解它的执行机制，很难设计出能跑长程任务的 harness 流程。
在执行一个超大任务的时候，单 agent 的执行流程大概是这样的：1）刚开始是高效模式，指令遵循效果特别棒；2）跑了大概 80k tokens 的时候，context 开始逼近 compact 阈值；3）紧接着，对话历史被压缩为摘要，模型开始忘记刚才修复单测的细节；4）再经过一两轮 auto-compact，它甚至会开始重复检查已修复的测试，当触发 maxTurns 并且 response 没有 ToolUse 指令时，模型会退出任务，然后开始询问用户："我已经修复了约 200 个测试，要继续吗？"
如果你在当前 session，回复继续，接下来的工作，它会做的更加不符合预期，并且退出得更快。
任何试图在一个 agent session 内完成海量工作的方案，最终都会碰到 context 膨胀 → compact → 信息丢失 → 效率下降的问题。
其实优化方向也特别简单，设计一个主-子 Agent 的运行模式（任务调度器），同时将任务进度写到 file system 中（进度持久化），每个子 agent 有独立 context、独立退出逻辑，主 agent 只负责调度和进度追踪，从而绕过单一 agent 的所有瓶颈。
因此给 cc 的指令需要包含至少这三部分：
1）任务分解。不要给一个无边界的指令（如修复所有单测），而是先扫描出所有失败测试，按目录或模块分组，每组 15-30 个，作为一个独立子任务。关键是每个子任务的 prompt 必须自包含——写清楚文件路径、错误现象、期望行为，不能写"根据之前的分析来修复"，因为子 agent 看不到父 agent 的历史。
2）进度持久化。在项目根目录维护一个 progress.json，记录 completed / failed / pending 三个列表。主 agent 每轮调度前读这个文件决定下一批任务，子 agent 完成后更新对应条目。这样即使主 agent 自己被 compact，重读文件就能恢复全部状态。
3）失败策略。子 agent 报错时，如果错误可修复，用 SendMessage 继续同一个子 agent（保留错误上下文更高效）；如果方向完全错了，启动新的子 agent 避免锚定在错误路径上；多次失败则上报用户，不要无限重试烧 token。
Claude Code 其实已经内建了这套能力。最直接的方式是启用 Coordinator Mode（输入 /coordinator），主 agent 自动变成纯调度者：它不执行任何实际工具调用，只负责理解子 agent 的返回结果、合成下一步的具体指令、并行派发独立任务；而每个子 agent 会通过 AgentTool 启动，它们有独立 context。
记住一句话就行了：设计多个 agents，各司其职、快进快出，把进度交给文件系统来记忆。
70 1320
Claude Code 程序的分发采用的是 Bun 作为运行时，源码通过 esbuild 打包成一个 JS bundle，并编译成 JavaScriptCore 字节码（JSC bytecode）装载在分发包中。
Bun 打包的时候有一个 fallback 策略，如果 JSC 加载失败，会去加载源码，因此分发包不仅包含了字节码，源码也保留了一份。
按照这个思路，将 CC 源码 dump 一份出来就不难了。
可以通过分析 Bun 的产物格式，做静态分析拿到 bundle JS，再将 bundle JS 运行起来，在运行时通过 hook 模块加载函数来 dump 各模块的源码，这个操作可以提取目录层级依赖关系。
唯一的缺点是，JS bundle 本身已经被 esbuild 压缩了一轮，变量名混淆了，直接阅读较为困难，但字符串字面量（包括 API 端点、prompt 模板、属性名等等）都完整保留了，因此交给 AI 去理解和阅读，没啥问题。
P.S. 反编译出来的代码也是可以正常 run 的。又多了一个持续跟进研究 Claude Code 功能的路子了，🐶
Bun 打包的时候有一个 fallback 策略，如果 JSC 加载失败，会去加载源码，因此分发包不仅包含了字节码，源码也保留了一份。
按照这个思路，将 CC 源码 dump 一份出来就不难了。
可以通过分析 Bun 的产物格式，做静态分析拿到 bundle JS，再将 bundle JS 运行起来，在运行时通过 hook 模块加载函数来 dump 各模块的源码，这个操作可以提取目录层级依赖关系。
唯一的缺点是，JS bundle 本身已经被 esbuild 压缩了一轮，变量名混淆了，直接阅读较为困难，但字符串字面量（包括 API 端点、prompt 模板、属性名等等）都完整保留了，因此交给 AI 去理解和阅读，没啥问题。
P.S. 反编译出来的代码也是可以正常 run 的。又多了一个持续跟进研究 Claude Code 功能的路子了，🐶
7 33
Claude Code 的成功，让市场对 Anthropic 多了很大的信心，它也是真下场啥都干，cowork，研发流水线，今天又来了个 Claude Design，接下来不知道还会去做啥。
一旦市面上出现了“Anthropic 出品即为精品”的预期，接下来就会出现两个结果。
1）传统 SaaS 生态会加速收缩与重组，很多原本独立存在的工具开始失去存在理由，因为用户会用脚投票。
2）竞争开始从产品转向协议，谁来定义任务如何拆解、上下文如何组织、Agent 如何协作，谁就掌握了新的基础设施。后来者只能向前兼容。
一旦市面上出现了“Anthropic 出品即为精品”的预期，接下来就会出现两个结果。
1）传统 SaaS 生态会加速收缩与重组，很多原本独立存在的工具开始失去存在理由，因为用户会用脚投票。
2）竞争开始从产品转向协议，谁来定义任务如何拆解、上下文如何组织、Agent 如何协作，谁就掌握了新的基础设施。后来者只能向前兼容。
21 31
Spec-driven development (SDD) 的通用实现基本会参照 openspec，实践下来，效果还是一般，大模型会偷懒，任务拆解不充分，也缺少 review 过程。
想让 Agent 持续跑长程任务，同时确保交付质量，需要让它明确项目目标，并将任务拆解到最小颗粒度，再让每个小任务在干净的环境下执行，执行之后，用子 Agent 对当前提交的代码进行 review，进入到 review → feedback → modify → review 的循环。
每个环节都需要精心构造最有效的 context，例如 review 过程，需要给定代码上下文、修改记录、验证手段、脚本工具库等等。
真实项目的执行过程，会包含立项、拆迭代、拆任务等过程，将这套流程复刻到 coding agent 的 plan 过程，依然奏效。如图一，它是一个跑了大概半天任务，而对于更复杂的任务，可以跑一两天不停歇。
每个 sprints 和 tasks 的执行过程，以及 review 的规范，尽量严苛，可以考虑编写脚本的方式来保障质量，例如架构必须分层，L2 可以调用 L1 和 L0，倘若 L0 调用了 L2 就是反模式，需要报错阻断，这种规则问题就可以交给 eslint + governance scripts 来保障的。code review 过程中，也可以要求 AI 根据需要，自主编写文档/程序来确保项目规则/脚本持续沉淀。
想让 Agent 持续跑长程任务，同时确保交付质量，需要让它明确项目目标，并将任务拆解到最小颗粒度，再让每个小任务在干净的环境下执行，执行之后，用子 Agent 对当前提交的代码进行 review，进入到 review → feedback → modify → review 的循环。
每个环节都需要精心构造最有效的 context，例如 review 过程，需要给定代码上下文、修改记录、验证手段、脚本工具库等等。
真实项目的执行过程，会包含立项、拆迭代、拆任务等过程，将这套流程复刻到 coding agent 的 plan 过程，依然奏效。如图一，它是一个跑了大概半天任务，而对于更复杂的任务，可以跑一两天不停歇。
每个 sprints 和 tasks 的执行过程，以及 review 的规范，尽量严苛，可以考虑编写脚本的方式来保障质量，例如架构必须分层，L2 可以调用 L1 和 L0，倘若 L0 调用了 L2 就是反模式，需要报错阻断，这种规则问题就可以交给 eslint + governance scripts 来保障的。code review 过程中，也可以要求 AI 根据需要，自主编写文档/程序来确保项目规则/脚本持续沉淀。
11 16
Agent 从数字世界触达物理世界，AI 可以点外卖、点咖啡、买机票、租房等等，省略了什么，又带来了哪些便利？
AI 托管的体验把效率推到了极致，但它没有解答两个问题，1）用户追求的是效率么？我非常享受一家家店点进去，挑菜选口味的过程，但今天变成了AI 告诉我吃什么；2）到底给用户省了多少时间？买一张从杭州到海南的机票，前后不会超过 10min，其中包括了航班对比。
还有第三个问题，也是最难搞定的，Agent 很难满足不同人的口味，它无法在巨大的 context下求解，也就意味着它会压缩人的上下文，在信息失真的情况下，只能靠不断询问用户来获得更多的信息，这种体验还不如直接用原始 APP。
现实里的很多行为，本来就不是效率问题。Agent 把世界变成了一系列可以被快速求解的问题，但人有时候并不想活在一个所有问题都被快速解掉的系统里🥲
AI 托管的体验把效率推到了极致，但它没有解答两个问题，1）用户追求的是效率么？我非常享受一家家店点进去，挑菜选口味的过程，但今天变成了AI 告诉我吃什么；2）到底给用户省了多少时间？买一张从杭州到海南的机票，前后不会超过 10min，其中包括了航班对比。
还有第三个问题，也是最难搞定的，Agent 很难满足不同人的口味，它无法在巨大的 context下求解，也就意味着它会压缩人的上下文，在信息失真的情况下，只能靠不断询问用户来获得更多的信息，这种体验还不如直接用原始 APP。
现实里的很多行为，本来就不是效率问题。Agent 把世界变成了一系列可以被快速求解的问题，但人有时候并不想活在一个所有问题都被快速解掉的系统里🥲
15 51
最近一两个月的 vibe coding 体验，逐渐意识到，AI 能解决的不仅仅是编码问题，工程、架构、设计，几乎一切跟软件相关的问题，它都足够擅长。
如果没有解决好这些问题，不是 AI 不行，只是没有消耗足够多的 token，以及没有让足够多的 AI 参与进来行动。
如果没有解决好这些问题，不是 AI 不行，只是没有消耗足够多的 token，以及没有让足够多的 AI 参与进来行动。
13 21