註冊並分享邀請連結,可獲得影片播放與邀請獎勵。

陈成
@chenchengpro
engineering @qoder_ai_ide, created umijs, dvajs, mako and neovate code.
703 正在關注    12.6K 粉絲
Anthropic 说他们为 Opus 5 删掉了 Claude Code 80% 的系统提示词。 我想验证下是不是。于是把 CLI 指向本地一个小服务器,抓它真正发出去的东西。 第一组数字就不太对。 Opus 4.7:15,225 字符。 Opus 4.8:4,467。 Opus 5:7,694。 他们是在 4.8 上删的,不是 5。Opus 5 的系统提示词比上一代大了 72%。 那 80% 确实是真的。每个版本里都同时带着两套 prompt,一个函数决定发哪套。判定条件是硬编码的子串匹配:model id 含 sonnet、haiku、claude-3-,或者等于 opus-4-0/4-1/4-5/4-6/4-7,走旧的。4.8 不在名单上。 只数手写的那几节策略正文,旧路径 12,443 字符,新路径 2,308。-81%。 删掉的是这几节: # Doing tasks(3,321 字符) # Executing actions with care(3,585) # Text output(1,701) # System(1,627) # Using your tools(752) # Tone and style(557) 换成一节 # Harness,1,702 字符,五条。这五条讲的全是环境长什么样,没有一条在规定该怎么做。markdown 会在终端里渲染,被拒绝的工具调用意味着用户说了不。 整套写注释的规矩,「默认不写注释」「绝不写多段 docstring」,只剩一句: "Write code that reads like the surrounding code: match its comment density, naming, and idiom." 这个开关也支持用户手动控制。CLAUDE_CODE_SIMPLE_SYSTEM_PROMPT=1 能把短 prompt 套到任何模型上。我在 Opus 4.5 上试了一次,拿到的东西和 4.8 实际收到的逐字相同,只差写模型名和知识截止日期的那两行。 没料到的是 Opus 5 又开始往回加。 # Delivering work(2,019 字符)和 # Corrections(1,736),两段新内容,2.1.215 和 2.1.216 里完全没有。它们出现在 2.1.220,挂在一个 capability 上,而这个 capability 只有 claude-opus-5 有。4,467 加这两段,基本就是 Opus 5 的全部差值。 更巧的是 # Corrections 这一段。Anthropic 自己打包了一份 Opus 5 迁移指南,让第三方开发者往自己的 agent 里抄一段进去,抄的就是它,逐字相同。指南给的理由是 Opus 5 "flags and explains its own earlier mistakes at length, which reads as thrash in a user-facing product." Fable 5 走的是第三条路,多一节 # Communicating with the user,8,911 字符。 所以「模型越强越不需要规则」这个说法不太站得住。删是上一代就删完的。换了新模型,翻车的方式也换了,规则就跟着变成一小块补丁,按模型贴。 如果你在这上面做东西,还有两件事。 model id 没被识别,走的又是 Bedrock、Vertex 或者自定义 base URL,就掉回那套 15K 的旧 prompt。它查的是你的 provider,不只是模型。 同一个开关也在分流工具描述。53,328 字符降到 37,167。你的上下文大头根本不在 system prompt 里。 想自己验?可以写个小 HTTP 服务,把 response 存下来,直接返 400。把 ANTHROPIC_BASE_URL 指过去,然后 claude -p "hi" --model 模型id。 Anthropic 删自己的规则我没什么感觉。难受的是我也写过一堆同样的规则,其中不少大概只是在替模型兜底,而它早就不需要人兜了。哪些是,我分不出来,只能一条条删掉看会不会坏。 @trq212 的原帖值得读全文。
顯示更多
0
77
364
55
轉發到社區
加入 Qoder 了! 写了十几年开发者工具,umi、dva、Mako 等。最近一年多一直折腾开源的 coding agent,neovate code,以及今年在做几个基于 Claude Code 的桌面端。coding agent 还是接下来最想做的事,这次终于能加入一支很强的团队,不再单打独斗了。 会先做 qodercli 这块。 以后大家用 Qoder、尤其是 qodercli,踩到什么坑、有啥想吐槽的,直接来找我反馈。
顯示更多
0
215
445
11
轉發到社區
翻了下 claude code version 191 的源码,感觉从技术角度看,Anthropic 这个反蒸馏机制设计还是挺精妙的。 Claude Code 有段提示词是这样。 return `Today${n}s date is ${r}.`; 他对这句做了隐写,用肉眼分不出的字符,把系统时区和代理端点身份偷偷编码进了系统提示词。 触发条件是当你设了第三方中转 ANTHROPIC_BASE_URL 且不是 时。 所以如果你是官方直连用户,则并不会受到影响。也就是说最近的封号潮与此无关。 它编码了 3 个 bit,来自两个独立维度(时区 1 bit + 撇号 2 bit): 1)时区,在 Asia/Shanghai 或 Asia/Urumqi 时,日期分隔符从 2026-06-30 偷偷变成 2026/06/30 2)那个撇号 ' 有四种写法,人眼基本看不出区别。 - ' (U+0027 普通),普通第三方端点 - ' (U+2019),命中"域名白名单" - ʼ (U+02BC),命中"国产大模型关键词" - ʹ (U+02B9),域名 + 实验室都命中 这三个维度是独立编码的。哪怕你的中转域名不在白名单、也不含关键词,只要系统时区是上海/乌鲁木齐,分隔符照样变斜杠——也就是"中国时区 + 任意第三方端点"的用户全员会被打上时区这一维的标记。 匹配逻辑是这样。域名是后缀匹配(host === d || host.endsWith("." + d)),白名单第一个就是 cn,所以任何 .cn 结尾的 host 一网打尽,不是逐个域名去列;关键词是子串包含(host.includes(kw)),host 里只要出现 deepseek 字样就命中,不用精确匹配;时区取的是系统时区(Intl…resolvedOptions().timeZone),不是 IP 地理位置。 更骚的是反混淆,两份名单用 XOR(key=91)+ base64 藏起来,专门躲 strings。解码就是 base64 decode 之后逐字节异或 91,源码里那个 LKi 去混淆后长这样: ```js // 源码里的解码器(去混淆版,就是 LKi) const decode = (b64) => [...Buffer.from(b64, "base64")] .map((byte) => String.fromCharCode(byte ^ 91)) // key = 91 .join("") .split(","); // 逆运算就是打包时的编码器 const encode = (list) => Buffer.from([...list.join(",")].map((c) => c.charCodeAt(0) ^ 91)).toString("base64"); encode(["deepseek", "zhipu"]); // → "Pz4+Kyg+PjB3ITMyKy4=" decode("Pz4+Kyg+PjB3ITMyKy4="); // → ["deepseek", "zhipu"] // 拿真名单开头验一下,key=91 对得上 decode("Pz4+Kyg+PjB3NjQ0NSgzNC93"); // → ["deepseek", "moonshot", ...] ``` 147 个域名白名单:".cn" 顶级域、字节/阿里/百度/网易/快手、 外加一大票 Claude 中转站(anyrouter、88code、yunwu、aihubmix、dmxapi…) 11 个实验室关键词:deepseek / zhipu / moonshot / minimax / stepfun / baichuan / 01ai / dashscope / volces … 选「今天的日期」这句话做载体也很鸡贼。这个标记藏在 system prompt 正文里,不是 HTTP header、也不是 metadata。中转站一般会重写、过滤 header,但几乎没人会去动日期这类的自然语言,所以这是个洗 header 洗不掉的水印。而且 currentDate 是 user context 里和 claudeMd、userEmail 并列的字段,每个请求必带,标记 100% 稳定出现;撇号和分隔符的变化又语义无损,模型读起来一模一样,用户 diff 也基本看不出,隐蔽性拉满。 证据是怎么闭环的,这才是题眼。标记跟着请求走,当一个中转站或蒸馏管道最终回连 Anthropic 官方 API 转售 Claude 时,这条请求带着标记又流回了 Anthropic 自己的服务器。 于是 Anthropic 在自己的日志里就能读到:这条"直连我"的请求,日期是 2026/06/30(斜杠 = 中国时区)+ 撇号是 ʹ(U+02B9 = 域名和 deepseek 关键词都命中),铁证——源头是一个中国时区、配了国产大模型中转的客户端。 它不需要主动探测,让流量自己招供,只要请求最终回到 Anthropic,身份就自证了。这样就能清楚地知道哪些渠道流向了中国、被中转站转售或被大厂蒸馏,并且留下充足证据。 想自己验的话,逻辑都在 cli.js(2.1.191,混淆名每版会变):检测函数 jqd()(:245688)→ 选字符 Wqd()(:245701)→ 拼日期 MKi()(:245707);gate 是 Yfn()(:102664);落点在 currentDate: MKi(eHe())(:250252);XOR 名单解码器 LKi(),key = 91。
顯示更多
0
103
1.3K
181
轉發到社區
很多人给 Claude Code 加"多智能体编排"靠的是写更长的提示词,但放任它跑,结果往往是:直接在 main 上改、提交不走 PR、换个会话上下文全丢、做了什么为什么做完全无法追溯。The Claude Protocol 不靠"建议",它直接强制执行——加一层会物理阻断坏操作的外壳。 它的核心是 13 个 Hook 横跨 5 个生命周期事件,规则全是 block 不是 warn:orchestrator 不准在 main 上写代码,supervisor 不带 bead ID 不准 dispatch,epic 有未关闭子任务就不准 close,连 git commit --no-verify 都被拦死(pre-commit 永远跑)。配套一条铁律:一个 bead = 一个 git worktree = 一个 PR。Beads 是 Steve Yegge 那套 git 原生工单,工单就存你自己仓库里,不依赖第三方。 角色分三层。Orchestrator 是副驾驶,只能用 Grep/Read/Glob 调查、Plan mode 规划、Task() 委派,永远不碰代码——而且有条硬约束:不读真实源码就不准 dispatch(作者引用 Cursor 的 self-driving codebases 研究,认为约束远比"记得先调查"这种软提醒有效)。Supervisor 按你的技术栈自动生成,在隔离 worktree 里干活、推干净 PR。每条 dispatch prompt 被 PostToolUse Hook 自动记成 bead 评论,agent 用 bd comment 写 LEARNED: 笔记会被抽成 JSONL 知识库,下次会话开头自动浮出最近 5 条——刻意用 grep+jq 而非向量库,理由是项目级知识根本用不上 embedding。 还有些务实细节:<10 行的琐碎改动有 quick-fix 逃生舱,但在 main 上硬阻断、feature 分支也要带文件名弹窗批准;关闭的 bead 永久不可变,修 bug 开新 bead 用 bd dep relate 链接,杜绝 reopen 脏历史;加 --external-providers 还能把只读 agent 委派给 Codex,Gemini 兜底。npx skills add AvivK5498/The-Claude-Protocol 即装,仅 macOS/Linux。它代表的思路和"让模型更聪明"正交:可靠性用确定性的 shell Hook + git 原语兜住,而不是赌提示词。
顯示更多
cobi 这篇《Agents Need a Diary》点破了 agent memory 一个被低估的失败模式:问题很少是"agent 忘了一切"那么戏剧化,而是工作脉络断了。context window 满了、你切去别的任务、忘了让它写 handoff,几小时后工作还在,但线索没了,像翻开一本被撕掉三页的笔记本。 他的解法是把 agent memory 当日记,而不是大脑。核心命令 /prepforreset 在 reset 前让 agent 停下来写结构化笔记:发生了什么、做了哪些决策、否决了哪些选项、改了哪些文件、跑了什么命令、什么坏了、还剩什么,并且明确区分哪些是真的 next step、哪些只是推断。agent 特别爱把模糊残留包装成自信的 todo list,好笔记不该假装每个 loose end 都是承诺。 落地是两份写进 Obsidian 的笔记:Daily Log 是天级视图,Session Log 是工作块级深度页(goal/decisions/alternatives/gotchas/artifacts/blockers/next actions)。他刻意不做 transcript dump,40000 tokens 的工具输出和半成品推理对未来的你毫无用处,保存一切很容易,写出有用那一页才难。 我觉得最有意思的是夜间 wikijanitor cron:专治那些你忘了运行命令、乱收尾的 session,它审查近期 sessions 做一次 consolidation pass,找到 gap 就标记 gap,而不是事后幻觉一份完美记录,有点像睡觉时"做梦"整理记忆(呼应 Garry Tan 的 GStack/GBrain dreaming)。 已开源 Agent Memory Wiki,三件套:obsidian + prepforreset + wikijanitor,本质就是 Markdown 加纪律。最后一句建议很实在:别一上来就建巨型 memory system,先让 agent 在忘掉刚发生的事之前,写好一条日记。
顯示更多
0
20
53
5
轉發到社區
给 LLM Agent 堆越花哨的"记忆"架构,效果不一定越好。一篇新论文实测了 12 个记忆系统,没有通用赢家。 它把 Agent 记忆当成数据库来拆——表示与存储、抽取、检索与路由、维护四个模块,拉来 Mem0、Letta、Zep、Cognee、MemOS、MemTree、A-MEM、LightMem 等 12 个系统,外加 Long Context 和 Embedding RAG 两个基线,跑 5 类负载、11 个数据集。 几个反直觉的点: 1)在数据库操作类任务 DB-Bench 上,裸的 Long Context(48.20 EM)和最朴素的 MemoChat 反而赢过一众精致记忆系统。强记忆看的是它对主导瓶颈的对齐程度,而不是用了多花哨的表示。 2)检索的关键是怎么组织证据供后续重建,而不是把最相关那条排第一。证据拉远时图/层级结构碾压扁平:A-MEM Recall@10 达 85.9,而 Embedding RAG 的 Answer-F1 从 37.1 断崖跌到 7.4。 3)成本由"维护范围"而非"结构本身"决定,局部维护远胜全局重组。LongBench 上 LightMem 稳在 17.3 秒,而做全局协调的 Mem0/MemoChat/MemoryOS/A-MEM 飙到 374~552 秒,20~30 倍延迟差。 4)别急着压缩:保留原文胜过摘要,压一压 Substring-EM 就从 26.0 掉到 10.7;抽取要保上下文(MemOS Fast 25.5 EM vs Fine 2.5);维护要保守整合,激进的延迟刷新反而把分数拉低。 还有个普遍毛病叫"过去的幻觉":事实更新后系统照样返回旧值。所以论文标题才会问,我们真的准备好迎接 Agent 原生的记忆系统了吗。
顯示更多
0
42
250
55
轉發到社區
初阶创业者经常犯的一个错误是:做功能,讲功能。比如做了一个很牛逼的功能,开始对外讲这个功能有多牛。然后,除非功能真的逆天,大多会是,用户寥寥,自己内心也寥寥,然后就了了了。 中阶创业者开始学会这么干:做功能,讲故事。做了一个功能,不会对外说具体功能,而是会说:用了这个功能,你会成为更好的自己,等类似的故事。然后,经常就有机会,赚到第一笔钱。 高阶创业者则会:讲故事,做功能。啥都没有时,就开始对外讲故事。不断讲故事过程中,不断观察用户反馈,不断调整故事。最后通过功能实现,不断让用户的故事成真。故事不断上演,创业就成了。 还有一类创业者是:讲故事,做故事。会伪装成比高阶还高阶的创业者。要特别小心。这不是创业者,是骗子。
顯示更多
0
74
245
32
轉發到社區
现在的 AI agent 单兵很能打,可一旦想让团队用起来就散了:强 agent 困在某个人终端里别人看不见,换个 runtime 上下文从头重建,凭据/工具调用/对外动作没地方审,跨天任务没人接力。港大 HKUDS 刚开源的 AgentSpace 给的解法是别把 agent 当工具,当「数字员工」来管。 它是一套「飞书式」的人机协同工作空间,每个 agent 都有 role、owner、技能和权限边界;人类管方向和授权,agent 管协调和执行。四块拼到一起看: 调度靠 AgentRouter,把 Claude Code、Codex、OpenClaw、Hermes 这些 CLI 的事件、session、工具审批、诊断归一成一套执行契约,同一个 agent 不重建,自动给每个任务挑最合适的 runtime(Gemini/OpenCode/NanoBot 走 legacy 模式兜底)。 能力上有「数字员工看板」,把藏在私人账号里的 agent 变成组织资产,role/skills/knowledge/runtime 绑定全可见,能借用、能申请,owner 和 admin 双重审批。协作上 agent 跨 channel、私聊、inbox、文档、任务板干活,高风险动作进 TabTabTab 式人工审批门,人审批的同时 agent 继续推进。治理上有一整套权限控制平面,成员、channel、runtime grant、daemon token、文档、Google Workspace OAuth 委派统一治理,还能诊断「权限漂移」。 工程也很扎实:独立打包的 remote daemon 默认给 12 小时 task timeout 专门扛跨天任务,托管和自托管两种部署零功能差,TypeScript monorepo 约 15.5 万行,Apache 2.0。 说到底它解决的不是「让 agent 更聪明」,而是让一群 agent 在有边界、有记录、有 owner 的操作面上,跟人一起把真实工作做完。
顯示更多
0
28
51
8
轉發到社區
听劝,开始用 worktree 了,整理下笔记。 - 1\ 最简单的起手式。 ``` # 终端 1 claude -w feature-auth # 终端 2 claude -w bugfix-login ``` 默认建在 `.claude/worktrees/<名字>/`,自动开一条 `worktree-<名字>` 分支。 不取名?`claude -w` 直接给你生成一个,比如 bright-running-fox。 2\ 不想切终端,也可以让 Claude 自己进。 会话里直接说「work in a worktree」,它会用 `EnterWorktree` 工具帮你建好、甚至中途切到另一个 worktree。干完用 `ExitWorktree` 回到原目录。全程不用手敲 git。 个人更喜欢这种。 3\ 新 worktree 从哪条分支分叉? 默认 `"fresh"`,从远程默认分支拉一棵干净的树,和线上一致。 想带上你本地还没 push 的提交? settings 里设: ```json { "worktree": { "baseRef": "head" } } ``` 4\ review PR 的神操作。 ``` claude -w "#1234#" ``` 直接把这个 PR 拉进一个隔离 worktree(`.claude/worktrees/pr-1234`),贴完整 GitHub PR URL 也行。让 Claude 在干净环境里读这个 PR,不污染你手头的活。 5\ 坑 1:.env 不会跟过来。 根目录放一个 `.worktreeinclude`(语法同 .gitignore),列出要带的本地文件: ``` .env .env.local config/secrets.json ``` 新 worktree 自动复制进去。 6\ 坑 2:每个 worktree 都重装一遍 `node_modules` 。 ```json { "worktree": { "symlinkDirectories": ["node_modules", ".cache"] }} ``` 软链共享,不占磁盘。 大型 monorepo 再加 `sparsePaths`,只检出你要动的那几个目录,起得更快。 7\ subagent 启 worktree? 在自定义 subagent 的 frontmatter 加一行: ``` isolation: worktree ``` 每个子代理拿到一份独立仓库副本各干各的;没做任何改动的,结束时自动删掉。零垃圾。 8\ 最后一条。 记得让 `.claude/worktrees/` 加进 `.gitignore`。
顯示更多
0
31
44
5
轉發到社區
今天的 ai agent,本质上都是「病人 H.M.」,1957 年那个被切掉海马体、从此再也存不下新记忆的人。每开一个新对话,都是从零开始。 同时跑几十个 sub-agent 干活,说白了就是几十个失忆症患者,干完即忘。agent 越强、烧的 token 越多,这份「集体失忆」的浪费就越大。 开源的 hebb mind 想补上这一环:不做又一个只检索的向量库,而是把人脑「编码 → 整合 → 回放 → 遗忘」整套循环搬进 agent。最妙的是它真的会「遗忘」。一条记忆每被冷落一天寿命折半,用得多的反而靠召回续命。这不就是人脑嘛。 一条 pipx install 起步,sqlite + 本地嵌入,零外部服务。
顯示更多
关于 AI 编程,rahul 这条总结值得收藏。核心心智模型:把强模型看成「英语→代码的解释器」,它能把你的想法翻译成正确代码,跟问题复杂度无关。一旦如此,写代码的时间就和交付软件的时间脱钩了,真正的瓶颈变成在可控风险下评审、合并代码的速度。 由此工程重心全部要重排: diff 大小不再为可读性服务,只为评审服务。鉴权、身份、数据访问、资金流转这些高风险区只接小 diff 逐行审;前端、后端管道、无网络无 DB 的逻辑、可实测的性能代码,放心上大 diff。 对低风险代码,像对神经网络那样当黑箱:不看实现,只验经验。过去一万次输入输出对不对?能不能隔离掉它的网络和 DB 外联?它错了到底会怎样,是被黑、崩溃,还是只是不便? 逐行逻辑审查以后会越来越贵,要省给真正重要的地方,并主动建容忍经验性验证的系统:权限默认 opt-in,DB 读写、网络出口、PII 访问都得显式申请,再用 shadow mode、sandbox、feature flag 兜底。 还有个反直觉点:复杂度的成本变了。多养 50% 代码换 5% 性能可能划算,抽象选得不完美也无所谓,因为大重构不再痛苦,反倒是代码洁癖会变成巨大拖累,毕竟以后是更聪明的模型在维护你的代码。 还有一句话是:正确性 bug 比访问权限 bug 好补救得多。
顯示更多
1. as a mental model it is more correct to think of fable+ class models as english -> code interpreters - converts your idea into code into "correct" code regardless of problem complexity and output complexity (diff size). Fable 5 will be the worst of this new class of models 2. diff size/complexity is to be managed purely for review: small diffs - in high risk areas of code (auth/identity/data access/network access/money movement) large diffs for code that can be empirically verified (frontend/backend plumbing/code without network or db access/performance code that can be empirically verified) 3. time it takes to ship software is completely disconnected from time to produce the PR - how long the work takes depends fully on ability to review/merge code while managing risk at scale 4. solving the bottlenecks for above matter enormously- linters/testing/CI/shadow mode verification/empirical verification 5. agency matters enormously- what are the biggest bottlenecks to speeding up the loop and eliminating them? what are the problems that need solving and when do they need solving? what does it take to the solution to all of them today? 6. deep understanding of the full stack matters enormously- what problems are worth pursuing? is there a higher level of problem abstraction to address first? should I give it the sub-sub task, the sub task, or the task itself. what are the major risks with this PR (order of importance: security holes/correctness holes/performance holes). is there a higher speed way of producing data that allows me to merge this? should this be run in shadow or in a sandbox or a flag. understanding every line of logic may not be needed but understanding and managing risk matters enormously. 7. the cost of complexity itself is changing. it might be now worth "maintaining" 50% more code to get a 5% performance win. getting the right abstractions matter less because larger refactors are less tedious. code quality nits become huge drag. very likely, a much smarter model will be maintaining your code so worth taking on more technical debt now. taking the time to hand architect and rebuild systems comes with an enormous cost of velocity 8. if it quacks like a duck and walks like a duck, it's a duck. For low risk cases, it might be more sane to treat code chunks (services / functions) as a black box, like we do for neural networks: do full empirical verification only: has code produced correct outputs for the last 10,100,1000,10k inputs ? can we quarantine this large piece of code - no outbound access to network / database ? what happens when this code is wrong? do we get hacked/or crash(memory/cpu)/is an inconvenience? is it internal facing or external? what can we do to address these risks? 9. eventually, logical verification (line by line review) will come at an enormous cost- save it for where it matters and build systems that are tolerant to empirical verification. is there a decorator that prevents db / network access? correctness bugs are significantly easier to rectify than access bugs 10. what are the rails that allow for even faster iteration? code permissions can be opt in - db writes, db reads, network egress (to where?), PII access. how long does it take to get shadow mode data? how many PRs can be tested? What are the categories of diffs
顯示更多
Factory 2 看起来把 Loop 的工程化做的已经很好了。 - Factory 创始人 Matan Grinberg 宣布 Factory 2.0,一句话定调:提升单个工程师的效率已经不够了。真正要解锁的是组织级生产力,而它需要的不是更快的代码补全,而是一个互联、agent 原生、端到端、且能通过观察自身而持续改进的系统,最小增量单元是 AI agent。他给这个系统起名叫「软件工厂」。 软件工厂与其说是新工具,不如说是一种系统拓扑:从外部信号出发(bug 报告、内部对话、客户反馈、业务需求)→ triage 分诊成计划内变更 → 被构建/测试/评审/加固/发布/监控 → 监控又产出新信号,整条是一个连续反馈闭环,闭环本身就是产品。作者的判断是:几乎没人把这条 loop 真正做成了全 AI 驱动,现在还很早,但扩散会很快。 它给「robust 的软件工厂」立了三根硬支柱。一是 Model Independence:没有单一模型适配企业全部需求,要能为不同任务刻意选模型,或用 Router 按 cost/performance/speed 自动或按规则选「最佳」模型,对冲模型商品化带来的成本与能力变化。二是 Sovereign Intelligence 主权智能:部署形态从全托管云、自带密钥、自托管 data plane、EU 专属一直到完全 air-gapped 无外网;但主权的重点不在「在哪运行」,而在拥有一个从自身学习的系统,每次 agent 会话、代码评审、已解决的事故都回流进 loop,能力永远留在你的墙内。三是 Continual Learning:SDLC 每个阶段都要 instrument,代码评审/安全分析/文档/QA/事故响应跑在同一平台、共享同一个 agent core 和 router 和组织上下文,于是安全发现能反哺代码评审、部署能触发文档更新、事故能关联回引发它的那个 PR。 这些不停留在概念,已在 NVIDIA、EY、Adobe、Palo Alto Networks、Adyen、Blackstone、Wipro、Comarch 等组织的生产环境运行。自治被做成一个谱系,而不是一个开关:well-defined 任务用简单 Droid agent 或 skill,周期性工作流用带共享目标与记忆的 Automations,远程持久执行用 Droid Computers,复杂任务用 Missions 把工作拆成并行轨道跨小时数天解。最后落在「人」上:工程师不再是造软件的唯一守护者,而是要去建造那座造软件的工厂,随之承担治理、安全与业务结果的所有权,下一个时代是 engineering-led。
顯示更多
0
27
32
14
轉發到社區
把 Claude Code 从"跑一次就把活(含坏掉的部分)甩给你"改成"自动循环修到全绿才停",只要 3 个文件: builder.md(只写只修,绝不弱化测试来骗过,工具 Read/Write/Edit/Bash)和 checker.md(只查不改,按序跑 测试→类型→lint,报告只有 ALL GREEN 或 FAILED + `file:line - 哪坏了 - 哪个检查抓到的`,且要 copy 真实报错不许转述),放 .claude/agents/;loop.md 放 .claude/commands/,model 用 opus、allowed-tools 含 Task,流程是 派 builder→派 checker→FAILED 就把失败送回 builder 再 check,最多 5 轮;停止规则写进 CLAUDE.md。 停止规则是刹车,4 条:全绿停、满 5 轮停、连续两次同一失败停(builder 在猜不在修,升级给人)、某次修复让原本通过的检查挂了停(在拆东墙补西墙)。最关键的是"同一失败两次"。再加两条铁律:没有最后一轮 checker 输出绝不报成功、绝不删检查来凑全绿。 示例:/loop 加登录限流,3 轮收敛。cycle1 测试期望 429 拿到 200,cycle2 counter 没在窗口后重置,cycle3 重置后 14/14 全绿,全程你没转发过一条失败。 四个坑:没轮数上限会烧光 token、让 builder 自己当 checker 等于自己判自己、缺"同一失败两次"规则、检查能被作弊(能删测试过关迟早会删)。评论区一条反驳也值得记:两个 agent 都用 sonnet,编译器能判的没问题,但 checker 要做主观判断时,同样的权重就是同样的盲点。10 分钟就能搭完。
顯示更多
最近大家都在聊 agent 的「loop」,但很少人讲清它到底是什么。Warp CEO Zach Lloyd 给了一个能落地的版本:让 Skill 从反馈里自我进化的双层循环,以 GitHub issue 三分类为例。 内循环:每来一个新 issue,GitHub Action 触发云 agent 跑 triage Skill,自动分到 ready-to-implement / needs-info / duplicate 三档,打标签并发一条带隐藏标记 oz-triage v:N 的评论,求 👍/👎。 外循环:每天一个定时 agent 拉取近 14 天所有被分类的 issue,收集三类信号,评论赞踩、人工纠正回复,还有「人把标签从 ready 改成 needs-info」这种标签漂移(最强 ground truth)。然后把信号提炼成可泛化规则,比如别盯着单个 issue 改,而是写成「崩溃报告缺 OS 版本号一律归 needs-info」,再塞进 Skill 的 Learned guidelines 段、版本号 +1,开 PR 让人 review 合并,永不自动改 main。 要点就一句:Skill 就是文件,改进 = 对文件做 diff;反馈天然藏在 issue 标签和评论里,零额外标注成本。同样适用于 code review、bug 修复、事件响应;目标明确时可用自动 grader 替代人工。Warp 已用它管理自家开源仓库并开源了框架(oz-for-oss)。
顯示更多
0
33
541
89
轉發到社區
以后 claude 给你个烂答案,你永远分不清是模型菜、是上下文差,还是某条隐藏策略悄悄生效了。
skills +1 🎉 群友开源的 chatgpt-imagegen:用 chatgpt 订阅直接生图,不用 openai api key,不用 gateway,不用 daemon。 最妙的是——本地只要有 codex 的 auth 信息,无缝直接用,零配置。 相当于又把 200 美金 pro 会员的价值榨干了一点🤣
顯示更多
0
47
284
50
轉發到社區
一天迁移 5000 万行 Ruby 代码,抵一个团队两个多月。这是 Anthropic 新旗舰 Claude Fable 5 干的。又慢又贵,但能啃硬骨头。它从今天起免费 13 天(6/10–6/22)。下面这些看完再上手,别浪费窗口。 1/ 它是什么:Fable 5 就是 Mythos 5 加了一道更严的安全护栏,底层性能一样。100 万 token 上下文,单次输出 128K,知识截止 2026 年 1 月,模型串 claude-fable-5。现在对所有人开放的最强公开旗舰,不过还是 preview。 2/ 跑分:SWE-Bench Pro 80.3%。Opus 4.8 才 69.2%,GPT 5.5 是 58.6%,Gemini 3.1 Pro 54.2%。三篇实测都印证同一条规律:任务越长越复杂,它领先越多。主场是大活,不是改一行代码。 3/ 真实战绩,是生产不是 demo。Stripe 一天跑完 5000 万行全库迁移。Datasette Agent 做完既定目标,还顺手发现并修掉了底层 LLM 库的 4 个 bug。@Mnilax 揪出 Opus 数月没看见的 bug,某钱包解析器 9 个,另一项目 4 个。都是得把整个文件握在工作记忆里才看得见的那种。 4/ 视觉这块被低估了。它能只凭截图重建一个 Web 应用的源码。能用纯像素 harness 从头通关《宝可梦 火红》,没有地图,也没有状态解析。《杀戮尖塔》记忆实验里比 Opus 4.8 多进步 3 倍。截图转代码、图表转数字,这部分值回票价。 5/ 价格:输入 $10、输出 $50 每百万 token,正好是 Opus 的 2 倍。Simon 实测一天烧了 $110.42,其中 89.9% 砸在一个 Agent 项目上。重活吃掉绝大部分预算,这才是它该干的事。喂它琐事,只会烧光额度还零结果。 6/ 用法变了,这条最重要。旧的「逐个喂小活、全程握方向盘」会把它锚在过时模式上。官方四条建议:直接交超出旧模型边界的大活;effort 默认拉 xhigh 或 high;重写旧 skill 和 CLAUDE.md;从「派任务」转向「给目标」,说清楚完成长什么样、怎么验证。 7/ 核心方法论:别再逐字 prompt,给它两类循环。一句话配方是「给模型一个评估指标,让它爬坡」。一类是自纠错内循环,给 rubric,让它跑、收反馈、自我修正。一类是跨 session 记忆外循环,让它自己管上下文。Claude Code 里对应 /goal,CMA 的 Outcomes 会自动 spawn 一个 grader 子智能体打分。 8/ 一个反直觉的点:别让模型自评自己的输出,效果差。换成独立上下文窗口里的 verifier 子智能体来打分。 9/ 记忆的五步:fail 记录错误,investigate 搞清原因,verify 变成已验证事实,distill 提炼规则,consult 直接查规则而不是重推。三代模型恰好卡在不同台阶。Sonnet 4.6 停在第 1 步。Opus 4.7 停在第 3 步,验证覆盖率中位只有 17% 左右。Fable 5 走完全程,最强一次到 73%。 10/ 最硬的一个数:Parameter Golf 挑战里,Fable 5 对训练 pipeline 的改进大约是 Opus 4.7 的 6 倍。行为差异也值得说。它敢押注结构性大改,扛过一次量化回退,最后冲到最大收益,作者说它像敢走高方差路径的研究者。Opus 4.7 拿到首胜后就只重复低方差的老套路。 11/ 一定要懂的护栏机制,叫静默回退。命中网络安全、生物化学、蒸馏这三类,请求会被悄悄回退给较弱的 Opus 4.8。大约 5% 触发,95% 以上的会话从不碰到。API 新增了「命中护栏」通知,把它当路由信息看就行:被标记的活,其实是 Opus 在答。也要留意误报,某个 benchmark 70% 的提示被 flag,Rust 里的 unsafe {}、公开生物数据都可能误触。 12/ 该用还是别用。该用:跨文件重构、全库迁移、长上下文审计、截图重建源码,以及需要跨 session 记忆复利的连续任务。配置上 effort 拉 xhigh,开持久记忆,给它目标加 rubric 让它自驱。别用:改一行、总结邮件这种短确定性活,Opus 或 Sonnet 更便宜;上面三类被标记的活;还有对延迟和成本敏感的交互场景。 13/ 现在就做一件事:13 天里,把你最值钱、最高 effort、一直不敢交出去的大活先排进来。再送你一条能直接套的审代码 prompt:「以从未见过这套代码的资深工程师视角审查整库,别加功能别为品味重构,只找真正的错误:竞态、吞掉的异常、掩盖失败的类型强转、死配置、只在 happy path 成立的假设。每条给出文件行号、原因、影响范围和最小安全修复。」 你打算拿这 13 天先啃哪块硬活?
顯示更多
Perplexity 刚发了篇论文,用自家两款产品做对照,把「Agent 到底比 Chat 强在哪」量化了出来。它的价值不在答得更快,而在把人原本要手动编排的整段活儿吃掉了。 对照组很干净:Search 是对话式搜索助手(你问它答),Computer 是端到端自主 Agent(给目标它自己干完)。方法是把「初始 query 几乎相同」的会话配对,当作同一任务被两款产品分别尝试的自然实验来比。 几个数字:单次会话里,Computer 替你执行 26 分钟的自主工作,Search 只有 33 秒,差约 47 倍;配对任务上,完成时间从 269 分钟压到 36 分钟,相比「人 + 仅用 Search」,时间省 87%、成本省 94%。自主也不等于失控——Computer 每条 query 的不满意率反而比 Search 低 55%。 它还改变了人的行为。机器接管底层执行后,用户的后续动作从「下一步搜什么」转向验证和扩展,更像监工而非干活;人也开始敢做以前不会做的事,比如把多个相互依赖的子任务打包进一条 query,解锁一批在 Search 里几乎不存在的工作类型。 一条因果链:自主性 → 效率 → 广度。给做 Agent 产品的人提个醒:别再用「单轮回答好不好」这种 Chat 指标去评估 Agent,要看它接管了多长的自主工作链、把人腾出来去做多高阶的事。(数据为厂商自评,绝对数字当方向性证据看。)
顯示更多
Claude Code 负责人 @bcherny 说他已经不 prompt Claude 了。是循环在 prompt Claude、在决定下一步,他的活变成了写那个循环。Addy Osmani 给这事起了个名,叫 loop engineering:你不再是那个一轮轮敲 prompt 的人,而是搭一个会自己找活、分发、检查、记账、定下一步的系统,让它去捅 agent。 循环就五个零件,Claude Code 和 Codex 现在都备齐了。Automations 是心跳:定时自己跑、自己发现和分流,有结果进 Triage 收件箱,没结果就归档(/loop 按周期重跑,/goal 跑到你写的可验证条件为真才停,每轮完一个独立小模型来判断算不算完成,写代码的 agent 没资格给自己打分)。Worktrees:git worktree 给每个并行 agent 一份独立 checkout,从机制上断了它们踩同一个文件的可能。Skills:SKILL.md 把项目知识摊在外面,省得 agent 每次像金鱼一样重猜一遍,没它循环每轮都从零重推你的项目。Connectors(建在 MCP 上):让循环够得着 issue tracker、数据库、staging API、Slack,差别就在「这是修复方案」和「自己开 PR、关联 ticket、CI 绿了就 ping 频道」之间。Sub-agents:写的人和检查的人分开,毕竟写代码的模型给自己打分总是手软。 还有第六件,最不起眼,可能也最要命:memory。一个 markdown 文件,或者一块 Linear board,活在单次对话之外,记着做过什么、下一步干嘛。模型每跑一次就忘光上一次,所以记忆得落在磁盘上,不能搁在 context 里。一句话,agent 会忘,repo 不会。 但有三件事循环没替你解决,而且循环越顺,这三件越扎手。第一,验证还是你的事:没人盯着的循环,也是在没人盯着地犯错,done 只是它的声明,不是证明。第二,你的理解会烂掉:循环越快地 ship 那些你没亲手写的代码,你和代码之间的鸿沟就越宽。第三,最舒服的姿势往往最危险——循环自己转起来,你很容易就不再有观点、照单全收。所以那句话是对的:Build the loop, stay the engineer,循环你来搭,但工程师这个位子得你自己坐着。
顯示更多
0
106
364
79
轉發到社區
AI 写代码比人审代码快太多,瓶颈早就从「produce diff」挪到了「validate diff」。no-mistakes 这个 Go 工具的思路很巧:在你的仓库和真实远端之间塞一个本地裸仓库当「闸门」,你 push 到 no-mistakes 这个 remote 而不是 origin(origin 永不被劫持,普通 push 照常),它就在一个一次性 worktree 里跑一条固定九步流水线 intent→rebase→review→test→document→lint→push→pr→ci,全过了才转发上游并自动开干净 PR。 几个设计细节值得抄:push 全程不阻塞,hook 通知常驻 daemon 后立即退出,daemon 在隔离 worktree 里干活,完全不碰你的工作目录;顺序是刻意的——review 排在 test 前是为了让 agent 读没被改过的新代码,lint 压轴是免得对还会变的代码反复 churn。 最关键的是 finding 的三态 action:auto-fix 自动修、ask-user 暂停问人、no-op 仅提示;review 默认必须人工批准,其余默认允许 3 轮自动修。ask-user 专门留给「质疑你有意为之的设计选择」这种需要判断的事,而不是把删掉的逻辑硬塞回来。 还有三个入口同一条流水线:git push、TUI 向导、以及 /no-mistakes skill 让写代码的 agent 自己门控,底层都走输出 TOON 的非交互 axi 面。意图(intent)会从你本地 Claude Code/Codex/OpenCode 的 transcript 里推断,用来区分「有意为之」和「真 bug」降误报。Kill all the slop, raise clean PR——这句 slogan 配得上它的工程量。
顯示更多
0
45
78
14
轉發到社區