Critical Read · 批判性精读

Agentic 之道，
把每句主张放回一手来源

彭超《Agentic 之道》是一篇命名密集的观点文：主线「代码 → Context → Agent Plan → 商业大脑 → OPC」方向站得住，但概念多为重新命名而非新发现，且几乎不给实证。这一页做三件原文没做的事——把每个概念对回 Anthropic / Karpathy / Every / Sam Altman 的一手出处，给出在 Claude Code / Codex 上到底怎么做，并补上支持与质疑的两面证据。

原文：《Agentic 之道》· 公众号 ChaoGeek（彭超），2026-07-06，GTLC 杭州站演讲整理版。本页结论由多源检索交叉核实（Anthropic 官方博客、X 原帖、Every、HackerNews、METR、GitHub、企查查/天眼查、GTLC 官网），每条附一手链接。

§1

先看主线：一条五段式脊椎

全文围绕一条演进链展开。点每一段，看它到底在说什么——以及它是不是原文自己的说法。

☝ 点一段主线，看它的实质与出处判定。

一句话总览：底层判断都能对应到真实的一手来源，方向没错；但「自造命名的密度」远高于「一手实证的密度」——这正是它读起来「有道理却模糊」的原因。

§2

七个概念，各归其位

每张卡三行：文章怎么说 → 一手出处是谁 → 判定。绿标=复述已有行业概念，蓝标=改名/包装，红标=作者自造、无一手对应。

Context 才是资产

复述·已有概念

文章说Prompt 是一次性对话；Context（你是谁、产品、用户、规则、禁区、品味）才随时间越攒越厚，是真正的资产。

一手出处「context engineering」由 Shopify CEO Tobi Lütke 带火（X · 2025-06-19），Karpathy 放大定义（X · 2025-06-25），Anthropic 官方定义为 prompt engineering 的「自然演进」（2025-09-29）。

判断成立，是全文最扎实的一段；「资产」的对偶句是作者的修辞包装。注意：Anthropic 说的是「演进」不是「取代」。

Vibe Coding 让你快，不让你强

复述·已有概念

文章说Vibe Coding 像许愿机：没记忆、没积累、不好管理，适合尝鲜不适合长期产品。

一手出处Karpathy 造词原帖（X · 2025-02-02）本就把它限定为「throwaway weekend projects（一次性周末项目）」，核心是「不看 diff、全部接受」。

准确转述。造词者本人早已给它划了「不适合生产」的边界，作者的批评与原意一致。

GCC — Goal / Context / Constraints

作者自造·无一手出处

文章说Agent 要同时立住三件事：Goal（去哪）、Context（知道什么）、Constraints（不能乱来），翻车多半是三缺一。

一手出处查无此三元组的行业出处。精神上与 context engineering、Anthropic 的 agent 设计原则相关，但「GCC」这个缩写是作者的原创归纳。

作为记忆抓手不错、也没错，但要当成「作者的框架」而非行业共识来引用。

Plan 五步闭环 + Compound Loop

半自造·一步有出处

文章说五步：Context Scout → Co-spark → Multi-lens Lock → Guarded Flow → Compound Loop（把结果/坑/模板写回 Context 形成复利）。

一手出处只有第五步有出处：compound engineering 由 Every 的 Kieran Klaassen 提出（every.to · 2025-08-18），原循环是 Plan→Work→Review→Compound→Repeat。前四个名字是作者对通用 agent 流程的重新命名。

「写回形成复利」是真 idea 且有出处（改名不改实质）；其余四步命名无外部来源。

Clawmancer（1 Lead + 6 Execute Agent）

品牌化·内核非原创

文章说作者的日常工作流：1 个 Lead 负责拆解编排 + 6 个 Execute Agent 负责执行复盘。

一手出处架构本体 = Anthropic 官方的 orchestrator-worker / lead+subagent 模式（Building Effective Agents · 2024-12-19、Multi-agent Research · 2025-06-13）。GitHub 与全网搜索「Clawmancer」0 结果——非公开项目。

「Clawmancer」是作者的私有命名（Claw 影射 Claude）；「6 个」是个人配置不是行业定数。技术内核是标准多 Agent 拓扑。

商业大脑

作者隐喻·非行业概念

文章说不是知识库（存东西），而是把知识、流程、品味、约束交给 Agent 反复运行的动态执行系统；让团队最贵的认知「不随人走」。

一手出处无对应行业术语。相关的真实工程是持久记忆层（Mem0、Letta/MemGPT、Graphiti、Cognee）+ harness 里的 CLAUDE.md/结果回写。

「商业大脑」是好用的隐喻，但它没有定义、没有方法、没有一手出处——是全文最「概念」的一处。

OPC — One Person Company / 一人公司

概念有源·缩写自造·争议大

文章说不是一个人辛苦干十个人的活，而是一个人拥有一家 AI 公司；人负责方向/判断/品味，Agent 团队负责执行。

一手出处内核 = Sam Altman「一人十亿美元公司」预测（访谈 · 2024-02，Fortune 报道）+ Paul Jarvis《Company of One》(2019)。Altman 未用「OPC」缩写。

概念有源，但这是全文争议最大的一段——见 §3 的质疑与 §4 的反面证据。

§3

落地实战：七概念 → Claude Code / Codex 怎么做

原文只说「要养 Context、要有 Plan」，没说在具体工具里到底敲什么。这一节把概念落到命令、文件、flag。一个巧合可当骨架：Codex 官方的四要素 prompt 模板 Goal / Context / Constraints / Done-when，几乎就是作者 GCC 的工程版——只多了一条「完成判据」。先把 GCC 三块逐一拆开。

G

Goal —— 先计划后写码，并给一个它自己能跑的完成判据

把「目标清楚」变成两个动作：进 plan mode 出方案，给一个可自动验证的「done」。

  • Claude Code 计划先行：Shift+Tab 循环 default → acceptEdits → plan，或 claude --permission-mode plan，或单条前缀 /plan。官方工作流是四段 Explore → Plan → Code → Commit：先只读探查，再产出计划（Ctrl+G 可在编辑器里直接改计划），批准后才执行。
  • 判断 什么时候跳过计划：官方原则——「能一句话描述这个 diff，就别写 plan」。改 typo、加日志、重命名 → 直接做；方法不确定 / 跨多文件 / 不熟这段代码 → 先 plan。
  • Claude Code 给可验证的「done」：官方核心论断「Give Claude a check it can run」——把验收标准和用例直接写进 prompt（write validateEmail; a@x.com→true, invalid→false; 实现后跑测试），UI 改动让它截图对比原图并列差异。要它「亮证据」（测试输出／命令返回／截图），不接受「声称完成」。
  • Codex 四要素 prompt：Goal（做什么）／ Context（相关文件）／ Constraints（标准与边界）／ Done-when（如「测试通过、bug 不再复现」）。复杂任务先 /plan，接受前 /review 看 diff；按难度调 reasoning（low/medium/high/xhigh）。
  • 大特性 让它反过来采访你：先一问一答逼出规格再写码——「Interview me one question at a time … then write a complete spec to SPEC.md」，然后开新会话用干净上下文执行 spec。

来源：Claude Code Best Practices · Codex Best Practices

C

Context —— 把「懂你」写进文件，而不是每次重讲

这就是原文「Context 才是资产」的落地：一个随项目沉淀的记忆文件 + 主动的上下文卫生。

  • Claude Code CLAUDE.md：/init 生成初版。层级从宽到窄、窄者优先：用户级 ~/.claude/CLAUDE.md → 项目级 ./CLAUDE.md（提交 git 共享）→ 本地私有 ./CLAUDE.local.md（gitignore）；@path 可导入其他文件。
  • 纪律 放什么／不放什么：放「agent 猜不到的构建/测试命令、与默认不同的代码风格、仓库约定、项目特有架构决策、环境坑」；不放「读代码就知道的、语言通用惯例、频繁变动的信息、『写干净代码』这种废话」。目标每个文件 < 200 行——臃肿会让 agent 忽略真正重要的指令。逐行自问「删了它 agent 会不会犯错，不会就删」。
  • Codex AGENTS.md（跨厂商开放标准，Codex／Cursor／Cline／Copilot 等 25+ 工具共读）：解析规则是「离被改文件最近的那个胜出」，分层合并 ~/.codex/AGENTS.md → 仓库根 → 子目录。想同时喂 Claude Code 和 Codex，社区通行做法是把 CLAUDE.md 和 AGENTS.md 做成 symlink，一份内容两边生效。
  • Claude Code 即时引用 & 沉淀：@文件 让它先读再答；/memory 编辑记忆、auto memory 自动把纠正/偏好记进 ~/.claude/…/memory/；只在相关时用的领域流程放 Skills（.claude/skills/name/SKILL.md），别塞进每次都加载的 CLAUDE.md；接外部系统用 MCP（claude mcp add），但官方说能用 CLI（gh／aws）就用 CLI，最省上下文。
  • 上下文卫生 克制胜于堆量：目标是「能达成结果的最小高信号 token 集」——窗口越长越出现 context rot（召回下降）。/context 看占用，不相关任务间 /clear，逼近上限用 /compact 只保留 API 改动。同一问题纠正超过两次，说明上下文已被失败方案污染——/clear 重开 + 写一条更好的 prompt，几乎总比在长会话里继续纠正强。

来源：Claude Code Memory · AGENTS.md · Anthropic · Context Engineering · Breunig · How contexts fail

C

Constraints —— 软约束写文件，硬约束写规则 / hook / sandbox

关键认知：写进 CLAUDE.md 的边界是「建议」，模型可能违背；要「硬保证」得用权限规则、hook 或沙箱。

  • Claude Code 权限模式（Shift+Tab 切前三个）：default（只读免批、其余问）／ acceptEdits（工作区编辑免批）／ plan（纯只读）／ dontAsk（锁死，适合 CI）／ bypassPermissions（=--dangerously-skip-permissions，只在容器/VM 里用）。
  • Claude Code 硬规则：settings.json 的 permissions 三类——allow / ask / deny，语法按工具：Bash(npm run test:*)、Edit(./src/**/*.ts)、Read(./.env)。deny 在所有模式（含 bypass）都生效，是最硬的边界。
  • Claude Code Hooks = 确定性护栏（「必须每次发生、零例外」）：在 .claude/settings.json 配。PreToolUse 能拦截工具调用（退出码 2 反馈给 Claude），Stop 事件可强制「测试不过不许结束」。想「绝不改 migrations 目录」——写 deny 规则或 PreToolUse hook，别只写在 CLAUDE.md。
  • Codex 两个正交维度（旧的 suggest／auto-edit／full-auto 已废弃）：approval_policy（untrusted / on-request 默认 / never）× sandbox_mode（read-only / workspace-write 默认 / danger-full-access）。安全默认 = workspace-write + on-request：沙箱内自主、越界才问。
  • Codex 联网默认关：要放开得在 [sandbox_workspace_write] 设 network_access=true；CI／无人值守用 codex exec + approval_policy="never"，高危的 danger-full-access / --yolo 只进隔离环境。~/.codex/config.toml + profiles（codex --profile strict）管多套环境。

来源：Claude Code Permissions · Hooks · Codex Sandboxing

其余四概念，同样落到手上

Vibe Coding 的解药

怎么用 AI 快，又不在生产里翻车

  • 读 diff、别 Accept All：Karpathy 本人对认真代码就逐行看 diff。长会话大 diff 用第 11 招（merge 前让它考你）收尾。
  • 给能自跑的验证器：测试 / build 退出码 / linter / 截图对比——有它循环自己闭合，没它「看起来做完」就是唯一信号，你被迫当人肉验证。
  • Claude Code 对抗式复核：收工前让一个全新上下文的子 agent 只看 diff + 验收标准复核（内置 /code-review）；但约束它只报「影响正确性」的 gap，否则会过度工程。
  • 放手就上沙箱 + 停止条件：要无人值守就在隔离环境跑（无网 Docker、只给测试凭证、设预算/最大迭代上限），而不是靠逐条点批准。

来源：Claude Code Best Practices · Willison · Designing agentic loops

Plan 五步闭环 / Compound Loop

把「写回 Context 形成复利」变成固定动作

  • 完整闭环（Every 版）：Brainstorm → Plan（研究后产出结构化计划存 docs/plans/）→ Work（隔离 worktree、每步跑测试）→ Simplify → Review（并行多个专职 agent）→ Compound（写回） → Repeat。
  • 写回两个固定位置：事实/偏好 → CLAUDE.md 加一条 note；可搜索的解法 → docs/solutions/（带 YAML frontmatter 按主题分类），未来会话自动检索到。
  • 缺陷升级成系统防线：一个 SQL 注入不只修当下——① 写进 CLAUDE.md 或 security skill；② 加一条 lint 规则；③ 更新 review agent 的 prompt 让它以后主动抓。金句「Every bug becomes a permanent lesson」。
  • Claude Code 现成插件：/plugin marketplace add EveryInc/compound-engineering-plugin 装上，用 /ce-plan /ce-work /ce-code-review /ce-compound，或 /lfg 一键串起全流程。

来源：Every · Compound Engineering · 插件仓库

Clawmancer / 多 Agent

orchestrator-worker 怎么用，以及何时别用

  • Claude Code 子 Agent：自定义放 .claude/agents/*.md（name + description 决定何时委派）；内置 Explore／Plan；@-mention 指定、或整场会话 claude --agent code-reviewer。并行：「Research the auth, db, API modules in parallel using separate subagents」。
  • 何时用 子 Agent = 上下文保护工具：当一个支线会把大量搜索/日志灌进主对话、且你之后不再引用时用它（独立上下文、只回传摘要）。也可路由到更便宜模型（Haiku）控成本。
  • 何时别用 官方明确：需要频繁来回、多阶段共享大量上下文、小定点改、或延迟敏感 → 用主对话。想复用流程但仍在主上下文 → 用 Skills 而非子 Agent。呼应 §5：Anthropic 说「单 Agent 覆盖 80%，别过度工程化」。
  • Codex [features].multi_agent 默认开；云端可并行跑多任务（各自独立 sandbox + git 状态）；跨 agent 转交/护栏用 Agents SDK 的 handoffs / guardrails。

来源：Claude Code Subagents · Codex Cloud

商业大脑 & OPC

把「经验变系统」和「一个人的执行半径」落到工具上

  • 商业大脑 = 记忆层 + 技能 + 品味编码：团队流程沉淀成 Skills、个人品味（命名/错误处理/测试策略）抽进 CLAUDE.md 偏好区和 review agent，接内部系统用 MCP。原则「Teach the system, don't do the work yourself」——留 50% 时间改进系统（建 review agent、写模式文档）。
  • OPC 的执行半径 扩大靠编排而非苦干：超出单会话上下文用 agent teams（各 worker 独立上下文、共享任务、有 team lead）；批量改用非交互 fan-out for f in $(cat files.txt); do claude -p "Migrate $f" --allowedTools "Edit,Bash(git commit *)"; done（先在 2-3 个文件上试 prompt 再放量）。
  • 但别忘了边界 §4 的质疑对 OPC 依然成立：能编排的是「执行」，接不住的是销售、客户信任、法律与道德责任。工具放大的是有判断力的人，不是把苦干自动化。

来源：Every · Teach the system · Claude Code · Automate and scale

一句话：作者说「养 Context、蒸馏知识、编排智能」——落到手上就是 写好 CLAUDE.md/AGENTS.md（养）→ 把踩坑写回 docs/solutions 与 skill（蒸馏）→ 计划先行 + 子 Agent + hook 护栏（编排）。概念是对的，缺的那层「怎么做」，在这一节。

§4

支持 vs 质疑：原文只讲了一面

文章是乐观的推介。把每个大主张的正反两面并排，你才看得到完整判断的空间。左绿=支持，右红=质疑。

① Context engineering 是真趋势吗？

支持Karpathy、DAIR.AI、Weaviate 等高信号账号一致认为是超越 prompt 的工程学科；Anthropic 出了官方定义与指南。
质疑HN 最高赞（915 pts）指为「失败的 prompt engineering 换名圈 VC 钱」；连倡导者 Simon Willison 都自认是 rebrand。

② 多 Agent 编排（1 Lead + 6 Execute）值得追吗？

支持Anthropic 实测：多 Agent（Opus 4 lead + Sonnet 4 子 Agent）在内部研究评测上比单 Agent 高 90.2%。
质疑同一篇 Anthropic 官方却说「单 Agent 覆盖 80% 场景，别过度工程化」；一线整理称 AutoGen/CrewAI「demo 好看、生产易崩，资深工程师已弃用」。

③ Vibe Coding / Agentic Coding 能上生产吗？

支持有人反对「vibe coding」这个贬义框架：认真用 Claude Code 建生产应用是可行的，「别再叫它 vibe coding，它就是 coding」。
质疑金句「以 10 倍速度制造 10 倍技术债」；撞墙点在鉴权/安全/支付/并发；生成代码把 bug 伪装起来、审查常比手写更贵。

④ OPC / 一人独角兽 是现实还是炒作？

支持工具/基建在快速成熟（Cofounder、多 Agent 编排产品）；Dario Amodei 称第一家单人十亿公司「2026，置信 70–80%」。
质疑十亿估值绕不开销售/信任/法律责任（AI 接不住）；最火的 Medvi 案例被拆是「减肥药引流站」；连 Altman 后来都改口说「10 人十亿公司」。

规律：作者站在「工具在变强」的一面，而质疑几乎都站在「人要担的那部分（销售、信任、责任、维护）AI 接不住」的一面。两面都对，差别在你把赌注押在哪。

§5

原文缺的硬证据，补在这里

全文没有一个数字或对照实验。以下四条是这轮检索里最硬的一手证据——正反都有，恰恰是「缺实证」印象的解药。

把这四条放回原文，「Agentic 之道」的判断依然站得住——但你会同时知道它的代价、边界和反例，而不只是它的好处。

§6

会议与作者：核实一下再信

既然要把它当学习材料，来源可信度也顺手查了。结论：真实，但有一处时间瑕疵。

✓ 会议与嘉宾属实。 GTLC 是极客邦/InfoQ 旗下真实的技术领导者峰会。官方页面（gtlc.infoq.cn/2026/hangzhou）逐字核对：鲁肃（程立，蚂蚁/阿里前 CTO）、叶军（前阿里副总裁）、汪源（杭州久痕科技 CEO、前网易研究院院长）均在嘉宾名单。
时间对不上（小瑕疵）。 杭州站官方日期是 2026-06-27（分站，非「总站」），2026 年至今没有 7 月场次。而文章 07-06 发、称「上周六」——实际已过去约 10 天。不影响实质，但「上周六」是不准确的。
作者可信度：有真实产品背书。 公众号 ChaoGeek 背后主体为深圳拾音教育咨询有限公司，产品是 AI 英语口语陪练 app OneOneTalk / 11Talk（小米商店 + 隐私政策页核实）。不过所有公开工商/应用记录里查不到「彭超」实名——应是运营者的专业身份/笔名。（作者身份核实证据强度：中；他是真做 AI 产品的人，非纯内容营销号，但实名无法在公开渠道确证。）
§7

自测：分得清「真概念」和「新名词」，也会动手

11 道题：既考你能不能把主张对回一手来源、守住批判视角，也考落地实战（GCC 怎么做、护栏怎么设）。答错会告诉你回读哪一节。全对解锁一句话总结。

0 / 11 已作答