ESC
↑↓ 选择↵ 打开esc 关闭⌘K 唤起
← Home NO.72
第 72 期 · AGENT 工程 · 收录于 2026 年 8 月 15 日

Anthropic平台生态

KA
Katelyn Angela · Sequoia Capital
视频 48:51 原文约 6.0 万字 预计阅读 23 分钟 来源视频 ↗ 中英对照全文
双人对谈 · 本期速读电台 00:00 / 31:00
TL;DR · 三句话
  1. Anthropic 平台把能力叠成三层蛋糕——knowledge(知道怎么用 Claude)/ execution(让 Claude 真正干活)/ coordination(协调多个 token 一起干),团队路线图的重心正从底层一路往顶层的「协调层」爬。(harness = 套在模型外面驾驭它的"脚手架/驾驶舱",负责喂上下文、调工具、管循环;token = 模型处理文字的最小计费单位)→ 详细
  2. 顶层的核心武器叫 strategies——一个「元 harness」:既然 token 并不可互换,就给每个 token 派一份不同的 job(出主意 / 执行 / 反思写进记忆 / 当裁判验收),再把它们编排组合起来。 这一层能榨出的价值,远比在底层 harness 上抠 prompt caching 要多。→ 详细
  3. 平台哲学是「开放生态,不是围墙花园」:内部和外部共用同一套 primitives(基础积木),不执着于让东西跑在自家基础设施上(上线了 self-hosted sandbox、MCP tunnel,跟 Modal / Vercel / Cloudflare / AWS 深度合作)——赌的是产品形态永远在变、没人能独占那个答案。→ 详细
01

两位嘉宾是谁 + 平台在 Anthropic 内部是什么位置

  • 对谈由 Sequoia Capital 主持,嘉宾是 Anthropic 平台的两位负责人:Katelyn Lesse(偏工程)Angela Jiang(偏产品)。主持人开场就把它定性为「全世界最重要的开发者平台之一,甚至可能就是那一个」。→ 详细
  • 平台是"一体两面":对外,是那套 API / 开发者平台——别人想构建能调用 Claude 智能的应用时,就在它上面搭;对内,它同时是 Anthropic 自家产品所依托的产品基础设施。外部开发者和 Anthropic 自己的 app,跑的是同一层地基。→ 详细
02

团队有"两个北极星":对内押速度,对外押赋能

  • Angela 坦言他们有两个 north star(北极星指标),因为对内、对外是「两个各自独立的太阳系」。对内:给内部团队尽可能大的杠杆,让他们能把"押注 AGI(AGI-pilled,笃信 AGI 会到来并据此设计)"的产品快速做出来发出去——"快"是被刻意强调的第一优先级→ 详细
  • 对外:让任何一个 builder 都能拿到工具、用 Claude 构建他们想要的任何东西。落地成一句话——"业务在哪儿,平台就贴到哪儿":所以他们花大量时间跟超大规模云厂商(hyperscalers,如 AWS、Google)做紧密集成。→ 详细
  • 一个金句判断:在 AI 新世界里,过去"经济上根本做不成"的**"定制软件最后一公里"**,现在理论上变得非常可行了。给开发者的东西有时是 primitives / API / 更高阶抽象,有时只是标准(如 skills 和 MCP)。→ 详细
03

内外共用一套 primitives,赌"产品形态永远在变"

  • 业界很多平台会把"对内 / 对外"分叉、分而治之;Anthropic 有意让两者对等,给所有人同一套 primitives——即便内部 builder 的需求略有不同(就像任何用户都各有需求)。→ 详细
  • 背后的统领性判断:模型能力在指数级上涨,你根本判不准哪种产品形态(form factor)能长久稳定。"两年前大家都说'一切皆 chat',现在又都说'别提 chat 了,全是 agent',往后还会有下一种、再下一种。" 所以最好的做法是把稳健的平台交给大家,让形态从市场里自然长出来——"我们绝不觉得只有自己才想得明白那个形态"→ 详细
  • Katelyn 补充团队纪律:一边在内部 dogfood(自己当用户先用),一边给外部客户开早期访问,两头拿反馈——避免"过度围着某个内部用户的问题打转"而掉进陷阱。→ 详细
04

抽象千层蛋糕:从一个 Messages API 长成开箱即用的 agentic 基础设施

  • Katelyn:她一年前加入时,平台基本上就只是一个 Messages API——一个无状态(stateless)的 API,外加 MCP 标准、SDK / 文档 / console 等开发者工具。→ 详细
  • 转折点:随着模型越来越能"长时间跑、处理更多上下文",客户开始想构建那种能在长跑式(long-running)、甚至无人实时盯着的远程场景里跑成功的 agent——而大家在反复解决同样的问题,这些也正是 Anthropic 自己在反复解决的。于是他们把内部搭产品用的那整套基础设施拼装成更高阶抽象,让你开箱即用就能做更多 agentic 工作→ 详细
  • 替你扛掉的两类苦活:① 基础设施——sandbox(隔离的临时运行环境,让 agent 在里面安全跑代码 / 改文件、用完即弃)的按需拉起与治理安全、会话记录的存储与断点续跑;② harness 工程——prompt caching(把重复提示词缓存下来省钱省时)、上下文窗口管理、从模型里榨更多智能、控成本。→ 详细
  • 客户怎么选这堆东西?Angela:看用户群——真正 AI 原生、爱在底层捣鼓的初创,直接冲 primitives 去;而典型企业、或"核心竞争力不在底层优化"的公司,会去够更高阶的打包方案(如托管式 agent,"这些你全帮我搞定")。→ 详细
05

【核心】三层栈:knowledge / execution / coordination

  • Angela 给出全片最关键的心智模型——这块蛋糕大致分三层:→ 详细
    • ① 知识层(knowledge):关于模型本身、模型所需的知识,本质是"知道到底该怎么用 Claude 把一件事做出来"。这层的 primitives 反而是些比较"老"、已定型的东西——Messages API 的结构与参数(呈现 Claude 怎么思考、怎么遵循参数、怎么做 tool call)、标准化的 tools,以及可在不同时刻塞进去的一块块上下文,具体就是 skills 和 memory→ 详细
    • ② 执行层(execution):知道该怎么做之后,你得让 Claude "去干活"——不只是回答问题,而是给产出、在一堆不同系统里改文件。"这就复杂多了,需要基础设施来支撑。" 这一层的抽象 = 一个底层 harness + 托管基础设施,今天最高阶的产品叫 Claude Managed Agents(托管式 agent),他们在把越来越多的零件往里裹。→ 详细
    • ③ 协调层(coordination):最上面这层,用来协调多个 token / agent 一起干活(详见下一主题)。→ 详细
  • 关键路线图信号(全片反复强调):在对外释放的抽象上,他们会越来越多地从知识层 → 执行层 → 协调层往上走。"归根结底你还是得执行,而执行仍需知道该做什么,所以所有这些东西应该像梯子一样层层咬合、递进上来。"→ 详细
06

【核心】strategies = 元 harness,"给每个 token 一份 job"

  • 协调层的核心概念叫 strategies(策略层)——"基本上就像一个 meta harness(元 harness)":真正的底层 harness 是为执行设计的;而上面这一层要解决的是——既然 token 并不可互换、你得给它们分派不同的活儿,就把这些编排好的策略组合起来。→ 详细
  • Angela 举的 token 分工例子:这个 token 负责出谋划策(advising)、那个负责执行(executing)、这个负责"做梦 / 发散(dreaming)"……→ 详细
  • Katelyn 把"给 token 派活"讲得更具体——同一个 token,你可以:① 纯拿去执行;② 让它回顾过去的 agentic 会话、把学到的东西写进 memory,好让下一个 agent 干得更好;③ 拿去跟一个更大的模型商量,好让一个更小的模型执行得更好;④ 执行完再来个"裁判(grader)"进来问:"你干得好不好?不好,重来。" 真正有意思的创新会更多发生在这个 meta 层。→ 详细
  • 一句可反复引用的判断:"在 prompt caching 该怎么做、context window 怎么清、evals 怎么写这些事上确实有最佳实践,但很多情况下那一层已经没多少油水可榨——相比之下,比它更高的那一层要划算得多。"→ 详细
  • 推到极致,这套东西收敛成一句话——"每个 token 都有一份自己的 job(活儿)",这是他们真正重仓押注的方向。他们内部随口就能给你五个 job;但把这套开放给整个生态,"人们能拼出来的组合估计得有十万、二十万种"。→ 详细
07

【核心】开放生态 vs 围墙花园:不执着于"跑在自家基础设施上"

  • 主持人直接问"开放生态 vs 围墙花园"怎么取舍。Katelyn 借三层蛋糕回答:在执行这类环节上,"我们其实并不执着于这些东西必须跑在我们的基础设施上"——非得是我们控制的 sandbox、我们控制的存储层。相反,会随时间做得更模块化。→ 详细
  • 具体动作(一串实打实的开放例子):上线 self-hosted sandboxes(自托管沙箱),跟 Modal、Vercel、Cloudflare 一大批伙伴合作,甚至包括 Amazon 新出的 microVMs,做成一等公民能力,你可以随便接;还上线了 MCP tunnels,让你能调用防火墙后面的 MCP server、把那层打通。→ 详细
  • 真正重要的不是它跑在谁的基础设施上,而是"你把这些 agent 组装起来的架构——得是强大的、可靠的、可扩展的"。在这一点上他们有很强的观点,你照着他们放出来的接口对接、插进来就行。→ 详细
  • 更高一层的"开放"是安全上的互操作标准:没人希望自己的服务上有技术在干坏事(网络安全是典型例子——防欺诈、护关键基础设施),所以要跟越来越多的人一起立标准。Angela 的电力类比:"在有电之前你只能点根蜡烛,能干的事很有限;电之所以是变革性的,是因为你能把它接进一切、人人都能用、还有标准和接入方式——而这不是任何一家能独立完成的。"→ 详细
  • Angela 补充生态愿景:一家公司成立后想 build 什么就 build 什么、需要就做自己的 agent,而这些 agent 能接到别的 agent 上去(有的是 Claude agent,有的是别人家的)——他们想让这种跨系统的"可交易 / 可互通"在全局成立。原生嵌合的方式如 connectors(建在 MCP spec 之上)→ 详细
08

要不要自己做 first-party 产品:两个判断框(form factor 实验 + TAM)

  • 框一:不断找"新产品形态"。 form factor 是动态的——某一年很棒的形态,下一年多半就不再棒;做出来火一年、不对了就扔掉重来。有时上线产品纯粹是为了"展示一种新形态",不是因为它是最大的肥肉。例子 Claude design:刻意做得"有主见"(直接跟它说话、让它自己搞定,弱化手动编辑),并想证明"纯用代码、让 Claude 直接生成,也能把设计 / PPT 做漂亮"——而非走传统 design system + 所见即所得(WYSIWYG)的老路。→ 详细
  • 很多这类形态实验由 labs 团队做,"内部先试一把、火个两周就转下一个,很多压根没上线"。→ 详细
  • 框二:看 TAM(总可服务市场),他们毕竟是一门生意。 偏向"吃 token(token-hungry)"的场景——判据是:干完一轮(turn)你会问自己"我做完了,还是庆幸干了、还想再多干"?喜欢答案是"还想再多干"的行业。coding 是典型:"干完一轮回头一看,'太牛了,我被解锁了,要 build 更多'";而有些服务干完一轮就完事走人。此外会挑特定业务职能当买家去服务,已透明公布的垂直化:金融、法律→ 详细
09

"展示可能性的艺术":同一件事秀出多条实现路径

  • 以金融为例,同一个结果有多条路:① 直接建在 Messages API 上拿 token、其余全自己搭;② 建在 Claude Managed Agents 上、开箱即用拿得更多;③ 做一个 connector / 插件,嵌进 Anthropic 某个产品里跑。 他们最近上线 Claude for Financial Services(打包好的 skills,可在自家或别人产品里用),还配了 cookbooks 教你怎么用 Managed Agents 落地。→ 详细
10

Claude Tag 的真正魔力:不是 Slackbot,是"组织级 harness"

  • 主持人:外界当时闹"这不就是个 Slack 机器人嘛",Tag 到底神奇在哪?Angela:"你在 Slack 里 @ 它,那只是界面,根本不是重点。重点是引擎盖底下那一整套 context engineering(上下文工程)和架构,好让 Tag 就这么'直接能用'。"→ 详细
  • 它该让你感觉像个同事:入职后一个同事进到你频道里,主动、能搞明白什么对你有用、直接帮你把事办了。对非技术用户是巨大解锁——"我到底该怎么再提交一次报销单?"传统上你得到处问主管、问搭档,现在直接跟 Claude Tag 说,苦活(上下文工程、主动性、大量 harness 部分)都由平台扛。Andrej Karpathy 有句话说得到位:这就像一个"组织级别的 harness(org-level harness)"。→ 详细
  • "有未来感"的部分是冰山:真正越来越难、越来越有价值的是水面底下那一大堆;而界面是可以不断替换的——今天 Slack,也可以是 Teams、WhatsApp 群、短信、邮件。"你完全可以想象 agent 就直接去到那些地方待着,几乎占据人类原本占据的那些形态。" 这是个"听着无聊、实则最有前瞻"的判断:让 AI 就像另一个很聪明、能搞清所有 context 的人在帮你。→ 详细
11

harness & context 最佳实践:先做对无聊的基本功,再往上抠

  • Katelyn 给的实操最佳实践(Claude Managed Agents 已把这些"又苦又无聊的细活"替你干了):① prompt caching——"做就对了,能省下一大笔钱和 token 成本";② 让 context window 保持清爽(把旧东西清出去,有时用编程方式调工具,避免把所有东西全拉进窗口);③ evals(评测集)——"我挺意外聊了这么久才有人第一次说出 evals 这个词",你需要它来确保你想达成的东西真有性能保障。→ 详细
  • 但她随即把重心往上引:这些底层细活"没那么有意思、也没多少油水",真正划算的创新在更高的 strategies / 元 harness 层(承接主题 6)。→ 详细
12

【核心】模型可引导了 → 大胆删掉"引导型脚手架",让它跑得更久

  • Angela 讲了个跟"代际"有关的深刻变化:两年前,harness 就是层脚手架,靠"在这儿砌一堵墙、那儿砌一堵墙"把模型从 A 点硬引导到 B 点走直线;而现在的模型已经非常"可引导(steerable,你说往哪走它就往哪走)",很多引导你直接写进 prompt 就行。→ 详细
  • 由此得出一条反直觉建议:"如果你的 harness 里有一部分是专门做这种引导的,那部分你可以删掉——我们经常鼓励大家删。" 这就是常说的"模型会把一部分脚手架给吃掉":只要方向是它自己能聪明想明白的,这种情况只会越来越普遍。→ 详细
  • 那 harness 接下来该干什么?从"引导"转向"让它跑得更久"(execution):既然它能朝你指的方向走,你就不会想让它到 B 就停——你会说"从 B 到 C、再到 F、再到 Z,然后就 A 这件事回来找我"。要做这一大堆事,你要的不再是"引导型 harness",而是"strategy harness"——让你在更高的思维层级操作,正好匹配模型的智能提升。→ 详细
13

通用 harness vs 任务特定 harness:验证逻辑和 token 预算才是"领域特异性"所在

  • 主持人问"任务 / 垂直特定的 harness 有意义吗"。Angela 的观点:有意义,不存在一个通用 harness。有些能力确实很通用很有用(coding 就是,因为软件已吞掉太多事);但具体领域总有几个部件要定制。→ 详细
  • 最该自己掌控的那一点,是"模型和你的执行之间的验证(verification)逻辑"——即做完一件事、交给模型时,中间的错误怎么 handle。"听起来是件小事,但我完全理解为什么有些人特别想自己掌控 harness,因为把最后这一点点调好,能榨出巨大的收益。" 尤其 legal、finance 这类高后果领域,没做到完全正确后果严重,这会决定用户最终用你还是用别人的产品。→ 详细
  • 另外两点:领域特异性真正重要的是验证逻辑 + 更高阶 strategies 上"你多会分配 token 预算";而**"context 这块其实有点被夸大了"**——任何 harness 都能处理大量 context,塞 context 更多只说明"你有数据",有数据你自然就有独特资格做有用的事。→ 详细
  • Katelyn 补一刀"为什么这么多分歧":大家说 harness 时指的东西根本不一样——可以只指一个循环(user→model→tool→…),也可以指连同打包的所有 tools。通用没意思的部分(prompt caching、清旧 tool call)该甩给平台;往上一层才是你想掌控的。终极目标是**"直接告诉 agent:这是我要的结果、这是我的预算,预备——开始,底下细节你压根不用想"**。→ 详细
14

从最先进用户身上学到的:创新集中在"context 和连接层"

  • 平台团队的独特视角是"能看到全世界最先进用户在用什么"。Angela 观察到的最兴奋的创新集中在"context 和 connectivity(连接)层"——它不表现为一个全新产品形态,而是"对用户极其有用"。有团队很聪明地处理散落各处的 context:怎么主动够到、在每处生成足够权限、再喂进一个 agent。→ 详细
  • 越来越多创新来自"内部用例"而非外部——即那些正变得更 AI native 的公司:有客户用极创新的方式给自己搭了套定制 SDLC(软件开发生命周期)、有的把整个后台办公室都这么改造,"他们把 context 流式接入的细微处理方式特别有意思"。→ 详细
  • 另一类有意思:跟老派软件打交道的公司——很多 healthcare 公司的系统"连 API 都没有,有 API 简直是奢望",于是用 computer use(让模型像人一样操作电脑界面) 去自动化、建连接;甚至有人拿一台笔记本跑一堆东西、自动生成给 agent 用。平台想为这块提供更多标准化支持("你有一份 spec,Claude 就能遵循它")。→ 详细
  • Katelyn 的连接层实例:一个客户想让分散在不同模型 / 平台上的 agent 协同——干脆"在一个 agent 上头暴露一个 MCP server,让另一个 agent 去调它的 tool",更模块化、能协作,"我们坐下来一起搞,跑得完美"。她还点了个行业趋势:coding 之外,manufacturing(制造业)开始起来,有个 PM 直接飞底特律去搞清客户要什么。→ 详细
15

从 token maxing 到 token rationalization:别叫停 AI,用"复杂度分流"

  • 主持人抛出一个好框架:历史先经历了 token maxing(把 token 用到极致),现在进入 token rationalization(把 token 用得合理)。Angela 认同:模型越强,你会先撞到"intelligence maxing(智能用到极致)",然后追下一个维度——要么成本、要么速度→ 详细
  • 最不该做的是"叫停 AI 使用"——很多公司 AI 花费是通过 shadow IT(影子 IT,员工绕过 IT 自行采购)爆发的,"等你反应过来,半个组织已经不知怎么装上了 Claude Code"。但如果你在拿回报、出货更快、运营更高效,那都是收益,别掐掉。→ 详细
  • 该做的是设计一套 strategy / 架构——任务进来先评估复杂度:"我这其实就是在描述一个 router(分流器)":难任务路由给又大又聪明的模型,简单任务路由给更便宜的模型。有技术复杂度但非常可行。但他们只在 Claude 家族内做这件事——"我们是在为 Claude 设计平台,不太有兴趣说'然后你该路由到另一个模型'"。→ 详细
  • Katelyn 的信念 + 类比:harness 和整个 agentic 层应该"绑定到你所用的模型家族"来调优(Vercel 就用 harness agent 往上抽象了一层:把整个 harness+agent 一起插进来、绑定模型家族)。她拿 Stripe 经历打比方——当年紧盯 AWS 账单,谁的后台 job 配错了在疯狂烧 CPU,就用护栏发现、客气地请他关掉;AI 时代也一样,危险的是简单粗暴"给你个上限、卡死在里面",正解是"鼓励创新做出成果,再从旁边看'同样结果有没有更省的几种做法'——一种是拿 Opus 通宵跑,另一种是在 strategies 上更聪明一点用更低成本做到"。→ 详细
16

接下来做什么:让你能"组合 strategies" + 被低估的第三根杠杆(best of N)

  • Angela 剧透路线图("这个词我们说了两千万遍了,抱歉"):在做让你能"组合 strategies(compose strategies)"的东西——即协调层的抽象。切入点是:大家在搭的问题都处在"要拿最大回报,就得对问题本质聪明一点"的层次。→ 详细
  • 具体例子 bug hunting(找 bug)agent:大家通常只想到两根杠杆——换更大的模型 / 让它跑更久;但其实有第三根、且往往管用得多的杠杆——best of N(同一任务跑 N 次、取最好的一次)。"说出这几个词很轻松,论文也一堆,但真把它搭出来、放进生产让你在真实用户身上测试,难得要命——你最后会搭出一堆定制 harness。" "真正的 alpha 就藏在这儿,而且它很难做" → 于是套用开头那句朴素哲学:"能带来你要的回报、又很难,那我们就帮你把它变简单。"→ 详细
17

agent swarm 只是"一种 strategy";两类 persona 与"入场门槛"

  • 主持人联想到一年前热议的 agent swarm(智能体集群)。Angela:那**"就是一种 strategy"**——就像"一个大 agent 再分出一堆小的"也是另一种 strategy;大家过去常照着"人类组织"来想这件事,但推到极致,本质还是"每个 token 都有一份 job"。→ 详细
  • 但在"把智能最大化"的爬坡之外,还有两类 persona 要照顾:① 企业客户——常说"我这有个 walled garden(围墙花园),得搞清怎么把方案插进来",需要企业级安全 / 合规管控、以及把平台做得更模块化可插拔("我这块想用 memory")+ 一流开发者体验,否则"你的创新再酷,我因为这样那样原因根本用不上";② 周末开发者——想给自己搭点有用的东西,往往同时用着他们和社区其他平台。→ 详细
  • Angela 把这些"更开放 / 更可 hack 的方案 + 打通体验"归为 table stakes(入场门槛),"但我对它们真的很兴奋,因为正是这些才能解锁——让人说'这玩意儿对我确实管用,现在我可以接上你们那些爬坡拿智能、省成本的创新了'"。→ 详细

本片无正式的 lightning round(快问快答)环节。收尾处主持人总结:"你们正在打造全世界最重要的开发者平台之一……我真心觉得很乐观——这个平台掌握在一双非常有想法、又真心在乎整个生态的手里。" 两位嘉宾致谢,全片在音乐中结束。→ 详细

本片未提及嘉宾联系方式。嘉宾:Katelyn Lesse(Anthropic 平台 · 工程)、Angela Jiang(Anthropic 平台 · 产品);主持方为 Sequoia Capital(对谈中提到 Lauren 与另一位主持人)。

🎯 于你何益 为你定制 · 非通用结论

相关度:极高。 你不只是这层平台的用户——你整套工作流(Holdwell PRD 工厂、app_incubator、Chief of Staff、乃至这本第二大脑的 AI 入口)就跑在这层平台上;而且你正在搭的两套多-Agent 架构,恰好就是两位嘉宾反复讲的"三层栈 + 给每个 token 一份 job"的活标本。这一期不是"顺带沾边",是给你的 agent 架构提供一手心智词汇表。下面按项目逐个对。


🥇 Holdwell PRD 工厂(三驾马车 + 碰撞协议)——本期最该榨干的一段

他们怎么做的:Anthropic 把 agent 能力叠成三层——知识(skills + memory)/ 执行(底层 harness + 托管基础设施)/ 协调(strategies = 元 harness);而协调层的灵魂是一句话——"token 不可互换,给每个 token 一份 job":出主意(advising)、执行(executing)、回顾过去会话把教训写进 memory当裁判验收("你干得好不好?不好,重来")。Katelyn 还点破一件对你尤其重要的事:在 legal / finance 这类"错了后果很严重"的高后果领域,最该自己掌控、也最能榨出收益的,是"模型和执行之间的验证(verification)逻辑",而不是别的。

你可以怎么做(把上面翻译成你的 PRD 工厂):

  • 把你的三驾马车,从"人类岗位"重贴成"token 的 job 类型"。 PM/UX/tech-lead 的分工就是照一支人类 PM 团队建模的(这正是 Angela 说的"大家过去照着人类组织来想");试着换个坐标轴重新点名:碰撞协议的各步骤里,哪些本质是 advising(出主意/发散)、哪些是 executing(产出初稿)、哪些是 reflecting(把本轮教训写回知识库)、哪些是 grading(验收打回)。同一件事按 job 拆,往往比按岗位拆更少冗余、更好编排。
  • 你的"真人评审意见回炉缺闭环"痛点,答案就是那个"裁判 token"。 Katelyn 的 execute → 裁判进来问"做好了吗?没有,重来" → 再 execute 就是一个能把活儿打回去的验证 job。把评审回炉做成一个"唯一职责是核对意见逐条落实、且有权 bounce"的 agent,而不是一个"提个建议就放行"的软环节——这正是评审从"建议"变"闭环"的机制。
  • 而且这件事你必须自己拥有、别外包。 ERP 是高后果域(一个需求错了下游一串返工),Angela 说"把最后这一点点验证逻辑调好,能榨出巨大收益,决定用户到底用你还是别人的产品"——这给了你一个明确的投资排序:harness 上别处都可以偷懒/交给平台,唯独"验证逻辑"值得你死磕。
  • 跨线对齐难 = 你的"知识层"还薄。 三层栈里知识层是地基(skills + memory)。Katelyn 描述的"让一个 token 回顾过去的 agentic 会话、把学到的东西写进 memory,好让下一个 agent 干得更好",正好是一条能自动喂厚跨线知识的产线:让"反思 job"在每轮 PRD 收尾时把跨产品线的稳定实体/术语沉淀进共享 memory,知识层就会随跑随长,而不是等你手动填。
  • "agent 产出的可观测/可验证",对应他们的 dogfood 纪律。 他们的做法是"一边内部 dogfood、一边给外部开早期访问,两头拿反馈",专门防"过度围着某一类用户打转"。你的工厂缺的就是这套"真的拿它跑真实需求、把结果收回来"的证据回路。

更深一层(镜子 / 可能的简化):Angela 那句"大家常照人类组织来想,但推到极致其实是'token has a job'"是给你的一面镜子——你的三驾马车,是"因为真实 PM 团队有这三个岗位"才这么分、还是"因为确实有三份独立的 job 需要它们"?按 job 重新收敛,很可能能砍掉一截 steering 脚手架(见下条),直接缓解你"评审不闭环、知识层薄"的结构性矛盾。


🥈 app_incubator(7-Agent 造 App 链路)

他们怎么做的:① "开放生态而非围墙花园"——不执着于跑在自家基础设施,靠 self-hosted sandbox、MCP tunnel、connectors 把别人的东西插进来;② "你有一份 spec,Claude 就能遵循它,于是你能非常自然地把一大堆东西连起来";③ 客户的神操作——"在一个 agent 上头暴露一个 MCP server,让另一个 agent 去调它的 tool",让 agent 之间更模块化、能协作。

你可以怎么做

  • 你的"设计稿即工程强制契约",正是 Angela 说的那份 spec。 这一期等于替你的核心押注背了书:把契约写成机器可遵循的 spec,就是把"连接"这件事从人肉对齐变成自动咬合。可以再往前一步——让 7 个 agent 之间也靠"各自暴露一个可被调用的接口"来串(她那句"agent 上暴露 MCP server 给别的 agent 调"),而不是靠一根写死的主流程把它们焊在一起,链路会更好插拔、好替换。
  • "把'该做什么'前移到 agent"这个痛点,对应协调层的 advising job。 你缺的那一环,是一个职责为"先想清楚下一步该干嘛"的 token(advising),它坐在执行 agent 前面,把"决定"和"执行"分开——这正是三层栈里"协调 > 执行"的那一格。
  • Claude design 给你一个信心样本:他们赌"纯用代码、让 Claude 直接生成,也能把设计做漂亮",且刻意"弱化手动编辑、就让你跟它聊"。这跟你"设计稿→工程"的方向同源;"activation / 首屏体验"痛点上,也可借它那股"有主见、替用户把默认决定做掉"的劲。

🔁 你本人 · 职业精力(这其实是本期最锋利的一面镜子)

他们怎么做的:主持人把历史分成 token maxing(把 token 用到极致)→ token rationalization(用得合理)。Anthropic 的态度不是"叫停",而是 Katelyn 那句——"同样的成果,一种是拿 Opus 通宵蛮跑,另一种是在 strategies 上更聪明一点、用更低成本做到"。加上 Angela 的"模型已经可引导了,harness 里那些'砌墙逼它走直线'的引导脚手架,可以删掉——我们经常鼓励删"。

这对你(精力=最稀缺资源)意味着什么

  • 把"精力"当 token 预算来 rationalize。 你现在多线并推、容易滑进"token maxing"式的蛮干——什么都亲自 Opus 通宵跑。这一期的正解不是"少做/设个上限卡死"(他们明说这是危险动作),而是重新设计 strategy 让同一产出更省力:哪些环节该 advising(想清楚再动,避免白做),哪些该直接甩给 agent 执行,哪些只需你当裁判验收。这跟你操作系统里的"杠杆 > 工时""99% 努力终将白费、盯那 1%"是同一句话的工程化版本。
  • 删掉你自己的"引导脚手架"。 你偏爱把流程/SOP 做得很重(多主题骨架、多 skill、多 gate)。Angela 的"模型会把脚手架吃掉"是提醒:你那些精心砌的"墙",有多少是为了逼一个两年前的笨模型走直线、而今天的模型自己就能走? 定期做一次"脚手架断舍离",把能删的引导层删掉,换成"让它跑得更久 + 末端验证"——省下的正是你的注意力。
  • "该 all-in 哪个编码下注" ↔ 他们选赛道的判据"吃 token、有迭代流:干完一轮会不会'还想再多干'"。拿这把尺子量你手上的副业:哪条线是"每投入一次就解锁更多、让你想继续"的复利型(像 coding 之于他们),哪条是"做完一轮就完事"的一次性——把精力压到前者。

📓 Personal Thinking(这本第二大脑)+ 🧭 Chief of Staff

他们怎么做的:知识层 = skills + memory;Claude Tag 的魔力"不是那个 Slack 界面,而是引擎盖下的 context engineering",被 Karpathy 称作"组织级 harness"——一个主动的、always-on 的、"像同事一样搞清你所有 context"的存在。

你可以怎么做

  • 第二大脑就是你个人的"知识层"。 你的"摄入 SOP / 信噪比 / 跨主题串联"三个痛点,恰好对应他们的 memory 与"连接层"。可借"反思 job 写回 memory"的模式:让一个固定环节在每次摄入后,把新笔记与既有主题主动连线(他们说最兴奋的创新就发生在"context 和连接层"),把串联从你手动做变成随摄入自动做——这也直接对着你信噪比与串联的痛点。
  • Chief of Staff 想成为的,正是一个"组织级 harness"般的决策同事。 Tag 的启示:价值不在界面(你在哪跟它对话不重要——Slack、命令行、还是这本库都行),而在水面下那套"把你写过的原则、你的处境 context 主动调齐"的工程。你 CoS 的"软教练质量""跨域守门"痛点,对应的就是把更多力气花在冰山下的 context 调度,以及那个"验证/守门 token"(同 Holdwell 的裁判 job)。

📈 StockHelp / 你的价值投资镜头(诚实中等相关)

  • 本片是"平台如何建"的内部视角,不含个股/估值信息,对看板要显示什么信号没有直接输入——这块诚实略过。
  • 但有一个可迁移的"生意质量"筛子值得进你脑内清单:Angela 选赛道用的"吃 token / 有迭代流:每用一次是否解锁更多",本质是在问一门 AI 生意的需求是复利型还是一次性。评估任何 AI 应用类公司时可顺手一问:"它的使用是越用越想用(coding 式复利),还是办完即走?"复利型更可能有量价齐升的护城河。这是投资心态层面的收获,不是 StockHelp 的功能输入——点到为止。
  • 另一个投资视角:Anthropic 的"开放生态 + 标准(MCP/skills)+ 贴着业务走 + 跟 hyperscaler 深度绑"是一套典型的平台护城河/网络效应叙事——可作你分析平台型公司(生态锁定 vs 围墙花园)时的一个对照模板。

🏠 小红书号 momorain(弱关联,一两句带过)

  • 平台工程内容与家居内容号基本不搭。唯一可迁移的一点:Angela"界面可不断替换、真正的价值在水面下的冰山"(t029)——对内容号是个温和的提醒:封面/形式(水面上)会过气、可随时换,真正沉淀的是选题与洞察(水面下)。仅此,不硬掰。

One Human Company 新号(2026-07 回填)

怎么做的:Anthropic 平台团队(Angela Jiang / Katelyn Lesse)给多-Agent 编排下了个反共识定义——"token 不可互换,给每个 token 一份 job":出主意(advising)、执行(executing)、回顾会话把教训写进 memory(reflecting)、当裁判验收("你干得好不好?不好,重来")。Angela 还点破:大家习惯照着人类组织来想 agent 分工,但推到极致其实就是"每个 token 都有一份 job"——按 job 拆往往比按岗位拆更少冗余。

你可以怎么做:这是一篇现成的 C 类验证体。候选标题:《Anthropic 说"别照人类公司搭 AI 团队",我把我的 10 个 AI 员工重排了一遍》——拿 drizzle tech 验:把 9+1 角色按"想/做/反思/验收"四种 job 重贴一遍,看能合并掉几个岗、编排后 token 账单差多少、哪里翻车,写出前后对比和你的判断(包括"哪些岗位确实该照人类组织留着"的诚实反驳)。闸门自检:删掉你的重排结果和账单数字后这篇只剩 Anthropic 转述,不成立——所以必须带实测发。可抄物:四 job 重贴清单。

怎么做的:Angela 给了条反直觉建议:现在模型已经很"可引导",harness 里那些专门"砌墙逼模型走直线"的引导脚手架可以直接删——"我们经常鼓励大家删";真正值得死磕的只有一处——高后果领域里"模型和执行之间的验证逻辑","把最后这一点点调好,能榨出巨大收益"。

你可以怎么做:这是 B 支柱(AI 员工管理)最独占的素材方向:给 drizzle tech 做一次"脚手架断舍离",记录删了哪些流程墙、返工率和 API 账单的变化,候选标题《我给 AI 员工松了一次绑:删掉一半 SOP 之后发生了什么》;同时把"唯一有权打回工作的裁判岗"写成 AI 员工的绩效制度贴——这正是 B 类"岗位说明书/返工账"的原型。可抄物:脚手架断舍离三问卡。闸门:返工数据和账单是你的,稳过。

怎么做的:他们选赛道的判据只有一句:干完一轮,你是"做完了走人",还是"太牛了、还想再多干"?只押后者(coding 式复利需求),一次性需求办完即走。

你可以怎么做:把这把尺子放进 A 类决策复盘的固定段落——第一个 App"为什么是它"就用"复利型 vs 一次性需求"讲取舍;它也是一句现成的 D 类立场句候选:"不解锁下一次使用的 AI App,不值得一个人公司做。"


所以呢(一句话行动)

这一期给你的不是灵感,是词汇表:回你的 Holdwell PRD 工厂,做两件事——① 把三驾马车按"token 的 job 类型(想/做/反思/验收)"重排一遍,顺手砍掉为老模型砌的引导脚手架;② 把真人评审回炉升级成一个"有权打回"的裁判 job,并让一个"反思 job"每轮把跨线实体/术语沉淀进共享 memory。这几下同时缓解你"评审不闭环、跨线难对齐、碰撞纪律难保真"三个结构性痛点。

接着读