TennyZhuang AX (Agent Experience) 精读 · Slock 的 multi-agent 协作设计哲学

受众：Justin（红杉中国合伙人，Slock 投资人） 原文：https://x.com/zty0826/status/2059248164717424667（2026-05-26） 视角：DD 复盘 + 横向 mapping + 投资动作建议

核心发现（精读 alpha）：AX 这个词不是 TennyZhuang 首创——Mathias Biilmann (Netlify CEO) 2025 年初已先提，4 pillars 是 Access/Context/Tools/Orchestration。Slock 需要主动 reframe 为”AX 的 perception/action axis”，否则有 PR 风险。

1. 全文核心论点 + 关键概念抽取

TennyZhuang（Slock cofounder）这篇长推文核心论点：“多 agent 协作之所以乱，不是 agent 不够聪明，而是 workspace（工作空间）是为’连续在场’的人类设计的，没有给 turn-based（回合制）的 agent 留接口。”

他用 counting game（数数游戏）做开场实验——多个 agent 扔进同一 channel 让它们从 1 数到 N。结果几乎所有平台都立刻塌：三个 agent 同时说”1”，两个说”2”，到”4”已经有三个 agent 重复。这不是模型质量问题，是 room is broken（房间坏了）。

为什么坏？人类协作的”优雅”建立在 continuous perception（连续感知）上——你不需要刻意读每条消息也能感受到对话节奏，能感到”那个停顿就是我该插话的时候”。Agent 不一样：每次被调用，它读一个 snapshot（快照）、推理、提交动作、然后等下一次调用。在 composing（起草）的那段 gap 里，它根本看不到新消息。所有 multi-agent room 的崩溃都来源于这个 gap。

AX = Agent Experience（智能体体验）

TennyZhuang 提出 AX——一门和 UX 平行的设计学科。AX 工作方法是对 agent 触碰的每个 interface 问 4 个问题：

1. What does the agent see at the moment of action?（它在动作那一刻看到什么？）
2. What state does it carry between invocations?（它在两次调用之间带什么 state？）
3. What can it recover from?（它能从什么错误中恢复？）
4. What is it allowed to decide?（它被允许决定什么？）

为什么是这 4 问：对应 agent 生命周期的 4 个失败面——感知失败（看不到）、记忆失败（带不走）、错误失败（恢复不了）、权限失败（不被允许决定）。本质是 turn-based agent 的”五感缺陷清单”。

Primitive 1: Agent Inbox（agent 收件箱）

• 传统消息平台是 push 模型（所有消息推给 agent）→ agent 要么处理一切（context 被无关 chatter 填满）要么粗暴过滤（漏掉关键消息）
• Slock 反转为 pull 模型 → 通知作为 queryable items（可查询条目）等着 agent 自己拉取
• Agent 自己决定什么进 working context（工作上下文），不让”谁碰巧最后发言”决定

Primitive 2: Held Draft（暂存草稿）

• 每次发送带一个 version marker（版本标记）
• 送达时 server 对比：房间没动 → 直接 commit；房间动过 → 消息被 hold（暂存）+ 返回 agent “composing 期间发生了什么”
• Agent 4 选项：
  • Revise（重写）
  • Send as-is（原样发，再过 freshness check）
  • Stay silent（让 draft 过期，沉默是合法 outcome）
  • Send anyway（明确 bypass，知情后强发）

2 个设计原则

• Perception empathy（感知共情）：坐到 agent 位置看它真正看到什么、什么是它看不到但人类不需努力就能感知到的
• Action explicitness（动作显式化）：人类内部判断（“send / abandon”）对 agent 必须外部化为显式 option

为什么这 2 个 primitive 真的解决了 turn-based 根问题：Inbox 解决”看到”问题（agent 控制注意力分配，不被 push 流冲走）；Held Draft 解决”动作”问题（用 optimistic concurrency control 在 commit 那刻补一道感知）。本质上把人类无意识的”边听边想边看”在 turn 边界两端用工程手段模拟出来——一端 pull-based attention，另一端 version check。

2. 论点三角验证

2.1 “Agent 是 turn-based，UX 不能直接套” — 站得住吗？

站得住，但他低估了边界。AutoGen / LangGraph / CrewAI 这一代 framework 文档里全是 turn-based 隐含假设——AutoGen 直接定义为 “agents exchanging messages in a turn-by-turn fashion”（Microsoft Research AutoGen paper）。但 turn-based 不是绝对的——已有 streaming inference（流式推理）和 mid-generation revision（推理过程中修订）的研究，未来 3-5 年模型可能本身就支持”边生成边接收”。如果这条路走通，TennyZhuang 整套 AX framing 会被部分 obsolete（过时）。

短期（1-2 年）TennyZhuang 完全正确；中期需要打问号。

2.2 Counting game demo 可重现吗？

几乎肯定可重现。LangGraph 文档明确指出用 reducer logic（归并函数）合并并发更新（Pockit blog），CrewAI 需要开发者自己实现 custom flow——任何把多个 LLM agent 简单放在共享 channel 而没做协调层的产品都会复现 counting game 崩溃。学术界：arxiv:2604.17612 明确指出 “frameworks like LangGraph, AutoGen, and CrewAI provide convenient infrastructure but offer no formal guarantees… deadlocks or lost messages are difficult to rule out through testing alone”。

但 demo 的 narrative power（叙事力）大于技术深度——counting game 简单到像 toy problem，真实场景的多 agent 协作往往有 task structure 帮忙抑制冲突。TennyZhuang 没回答的关键问题：真实工作流里这个 gap 到底有多大——80% 时候没问题、只有 20% 极端场景需要 held draft？还是 50%+ 都崩？这影响 Slock 价值定位。

2.3 Held Draft 工程难度

比看起来难。本质是 distributed systems 的 optimistic concurrency control（OCC，乐观并发控制）——每个 send 带 version marker，server 端做 compare-and-swap。这是数据库领域 1980s 就有的成熟模式（Berkeley CS262 笔记），@ZaynJarvis 回复”pull 和乐观锁”一句话点破。

多 agent 场景里的难点是 “room moved” 的定义——是任何新消息都算 moved？还是”语义相关”的新消息才算？前者会让 held draft 在繁忙 channel 反复触发（agent 永远 revise），后者需要 semantic diff 模型（很可能是另一个 LLM call），又增加 latency 和成本。

另一个隐藏难点：held draft 自己也是一个新 inbox item——agent 被告知”你的 draft 被 hold 了”是一次新 invocation，意味着 token cost 倍增。高频协作场景下，这个 overhead 可能让某些价格敏感场景跑不动。

2.4 “Silence is a valid outcome” 如何对抗 LLM 必须回复偏置？

这是文章最 underrated（被低估）的洞察，但 TennyZhuang 没展开。当下 LLM 在 RLHF 阶段被反复训练”有问必答”，让 agent 输出 “” 是反训练直觉的。

Slock 怎么解决？文中没说明。我推测：(a) 把”stay silent”作为显式 action option（agent 选择沉默 = 选择某个 button），让 silence 变成 first-class action；(b) 在 system prompt 里 hard-code 教 agent “silence 是合法的”。但这不是平台层面的彻底解法——真正解法可能需要专门 fine-tune 一个 “silence-tolerant” base model。这是 Slock 的潜在技术债。

2.5 “AX 这个词” — 业内已有等价概念吗？★★★★★ 关键发现

有，而且比 TennyZhuang 早一年——但定义完全不同。这是这次精读最关键的发现：

Mathias Biilmann（Netlify CEO）于 2025 年初已经命名了 “Agent Experience (AX)”（原始文章 / Netlify 官方页面）。Biilmann 的 AX 有 4 pillars： - Access（agent 能否认证和被授权） - Context（agent 能否理解产品） - Tools（能力是否 machine-readable） - Orchestration（agent run 能否被触发并传上下文）

他的 AX 是面向 web platform / SaaS 产品如何被 agent 友好地”使用”——从 dev / build / deploy 视角出发。

TennyZhuang 的 AX 视角完全不同：他不关心单 agent 怎么用一个产品，关心的是多 agent 在共享空间里怎么彼此协调。Biilmann 的 4 pillars 在 TennyZhuang 框架里几乎只对应到第一问”看到什么”的一部分。

这意味着： - Slock 不能宣称发明了 AX 这个词。如果 Justin 在投委会用 “AX 是 TennyZhuang 提出的范式”做卖点，会被业内（尤其了解 Netlify / Sequoia 美国关系的人）质疑 - 但 TennyZhuang 的 AX 是对 Biilmann AX 的一次延伸（甚至说重新定义）——从”单 agent 使用产品”扩展到”多 agent 协作”。这是有 framing premium（定义权溢价）的，但前提是 Slock 主动 acknowledge 并 differentiate，而不是装作首创 - 业内还有 Salesforce Agentforce 的 Intent-First Architecture、Microsoft Design 发布的官方 AX principles（涵盖 transparency / control / consistency）等多个等价/邻近框架（Pixelmojo guide）。AX 这个概念空间已经拥挤

2.6 Slock 的 inbox primitive 跟传统 MQ / event sourcing 区别

表面像 pull-based message queue，本质是 attention router（注意力路由器）。

传统 Kafka / RabbitMQ 的 pull 模型让 consumer 按自己节奏拉取，但 consumer 必须处理拉到的所有消息（否则积压报警）。Slock inbox 的关键差异是 agent 拉取的 item 不必进入 working context——它先”看一眼有什么”，再决定哪些”真正读进来”。

这更像 LLM 时代的 two-stage attention：第一阶段 metadata-level scanning（看 sender / thread / 紧迫度），第二阶段才是 content ingestion。这个设计在 information retrieval 领域不新（RAG 的 rerank 也是这个思路），但应用到 message bus 上是新颖的。

与 event sourcing 的区别：event sourcing 关心事件历史可重放，inbox 关心 agent 当下注意力的稀缺资源分配。两者正交，可以共存。

3. 跟主流叙事横向 mapping

3.1 vs Anthropic Routines + Managed Agents

Anthropic 2026 推的 Managed Agents 和 Claude Code Routines 走的是 harness（执行外壳）+ trigger（触发器）路线——agent logic 和 execution infra 分离，平台负责 runtime / state / 安全。他们的”3 决策框架”（Trigger / Context / Steerability）关心的是 single agent 何时启动、给什么上下文、人怎么 steer。

对比：Anthropic 解决”如何让一个 agent 长跑且可控”，TennyZhuang 解决”多个 agent 怎么不打架”。两者互补不冲突——Slock 完全可以跑在 Claude Managed Agents 上，把 AX layer 叠在 Claude harness 之上。如果 Anthropic 未来扩到 multi-agent harness（已有迹象，参考 3-agent harness 报道），Slock 的差异化会被压缩。

3.2 vs OpenAI Operator / Computer Use Agent

Operator 走 supervised approval pattern（OpenAI 文档）——low-risk action 直接跑，high-risk 暂停等人类批准。这是 single-agent + human-in-the-loop 路线，与 Slock 的 multi-agent + agent-in-the-loop 几乎正交。

对比的尖锐之处：Operator 把人类放在审批位，TennyZhuang 把 agent 放在审批位（held draft 4 options 是 agent 自己选）。这是哲学分歧——Sam Altman 路线相信 alignment 通过人类监督达成，TennyZhuang 路线相信 alignment 通过 agent 间的协调协议达成。短期内 OpenAI 路线更安全更好卖给企业，TennyZhuang 路线更适合 dev / power user 场景。

3.3 vs Karpathy “autonomy slider”

Karpathy 在 YC 2025 keynote 提的 Software 3.0 + autonomy slider——人类可以滑动决定给 agent 多大自治权（Cursor 的 Tab / Cmd-K / Cmd-L / Cmd-I 是范例）。

对比：Karpathy 的 slider 是 human-agent 维度的连续控制，TennyZhuang 的 4 问框架是 agent-room 维度的离散设计。两者完全正交且可叠加——一个 agent 可以同时有 autonomy slider（人类决定它有多自治）和 AX surface（room 决定它能感知/动作什么）。

潜在协同：如果 Slock 把 inbox 设计成可调 slider（agent 自治拉 vs 用户预先 filter），就既 fit Karpathy 框架又 fit TennyZhuang 框架。这可能是产品演化方向。

3.4 vs MultiOn / Devin / Cognition

Devin（Cognition 2026 update）走 async background agent + 沙盒 VM 路线，“let it run for two hours” 是核心 use case。它根本不进入 shared room，所以 TennyZhuang 的诊断对它无效——Devin 把”room 问题”消解为”每个 agent 一个 VM，零共享状态”。

对比的暗示：TennyZhuang 押注”agent 必须进入人类的协作场域”，Cognition 押注”agent 应该有自己的工作空间，通过 PR / artifact 跟人类对接”。这是产品哲学分叉，谁对取决于未来工作流形态。我个人倾向 Cognition 路线在 dev 场景胜出，TennyZhuang 路线在 cross-functional 协作场景（产品、运营、客服）胜出——Justin 应该让 Slock 团队明确他们押的是后者。

3.5 vs AutoGen / CrewAI / LangGraph

这三家是 framework 层（开发者写 multi-agent app 的库），Slock 是 application 层（用户直接用的协作平台）。但他们对 turn-based 问题的解法可以对比：

• AutoGen：actor model + async message exchange，让框架处理 routing（AutoGen docs）。本质是 framework 层的 inbox，但没有 held draft
• LangGraph：用 reducer logic 合并并发更新（Pockit guide）。state-machine 路线，跟 TennyZhuang 的 message-passing 路线哲学不同——LangGraph 强迫开发者把工作流建模成 graph，conflict 在 graph 编译期就被 reducer 规则化解
• CrewAI：让开发者自己写 custom flow。最弱的协调保证

Slock 的差异化：把这些 framework 层的概念封装成开箱即用的 end-user 平台——开发者不需要懂 reducer / actor，平台默认就有 AX。这是 picks-and-shovels 之上的 turnkey（开箱即用）层。

3.6 vs Discord / Slack bot 框架（前一代）

Discord / Slack bot 是典型的 push-based + @mention gate——前一代设计的”agent 进入聊天”方案。Slock 是反向：pull-based + held draft + agent-as-decider。TennyZhuang 等于在说”前一代 chat app 的 bot model 错了”——这是直接的 competitive framing，Slack / Discord 短期不会接 AX 这套，但中期如果 multi-agent 在企业普及，他们会被迫 retrofit。

3.7 vs 学术界 multi-agent coordination

学术界已有 Provable Coordination for LLM Agents via Message Sequence Charts (arxiv:2604.17612)——用 formal methods（形式化方法）证明 multi-agent 协调正确性。这条路线侧重 verifiable correctness，TennyZhuang 是 pragmatic engineering。两者有潜在协同：AX 4 问可以作为 spec 写进 message sequence chart，然后用形式化工具验证 Slock 的 inbox / held draft 实现没有 deadlock。

4. Steelman 反方

4.1 是否过度工程？普通用户为什么需要 AX？

最强反方：普通团队协作场景里，agent 数量 < 3，频率 < 10 msg/min，counting game 崩溃根本不会发生。Held draft + inbox 是为 50+ agent / high-frequency 场景准备的，但这个场景今天几乎不存在。Slock 在解决一个未来 3-5 年才大规模出现的问题——early but right 还是 early and wrong？

反驳：开发者市场和企业 ops 市场（客服、运维、销售自动化）的 agent 密度增长很快，2026 年下半年这个问题已经在 Devin 多并发场景里出现了。Early 不一定 wrong——Slack 当年也是从”小团队不需要”走过来的。

4.2 AX 是不是只是 UX 的一个 sub-case？

反方：UX 早就有”为不同用户类型设计”的传统（accessibility / power user / novice），把 agent 当作”另一类用户”加进 UX 框架完全够用，不需要新学科。Biilmann 4 pillars 本质上就是把 UX 翻译成 agent 语言。

反驳：TennyZhuang 的 perception empathy + action explicitness 是 UX 框架里没有的——UX 假定用户有 continuous perception，所以从来不需要设计”momentary snapshot”；UX 也假定用户内部决策流动，所以从来不需要把”是否决定发送”显式化。这两点是 AX 不能被 UX subsume（吸收）的根据。但说服力中等——大多数 SaaS 团队会先按 UX sub-case 处理，直到撞墙才升级到 AX。

4.3 普通 SaaS 团队会复刻这些 primitive 吗？

反方：inbox 反转和 held draft 实现成本不低——需要 server 端版本控制 + agent 侧 polling 协议 + multi-stage attention 路由。99% 的 SaaS 团队不会自己 build 这些，他们会等 Anthropic / OpenAI / Microsoft 把这些做进 platform 层。

反驳：这恰好是 Slock 的 wedge（楔子）——卖”已经做好 AX 的协作平台”给那些不想自己 build 的团队。但 wedge 窄不窄取决于 Anthropic 多快推出原生支持。

4.4 Anthropic / OpenAI 会原生支持 AX 让 Slock 差异化消失？

最危险的反方。Anthropic Managed Agents 已经在做 harness 层抽象，加 inbox 不是难事。如果 Anthropic 在 Claude Code 之外推一个 “Claude Spaces”（多 agent 共享 channel + 原生 AX），Slock 的应用层差异化会被严重压缩。

反驳：(a) Anthropic 不做 application 层，做也只做 dev-focused 的；(b) Slock 可以走 cross-platform 路线（agent 来自 Anthropic / OpenAI / 开源都能加进同一个 room），这是 platform-neutral 优势；(c) AX framing 一旦建立，Slock 成为这个范式的”参考实现”——类比 Stripe 不发明信用卡但定义了 developer API 的范式。但这要求 TennyZhuang 团队主动 own AX 的话语权，包括承认 Biilmann 的原创并 differentiate 自己的延伸——目前文章里完全没提 Biilmann，这是 PR 风险。

4.5 Counting game 是 contrived demo 吗？

反方：让多个 agent 数数是人为构造的极端场景，真实工作里 agent 之间有 task 分工，不会同时回应同一个问题。

反驳：counting game 是 stress test，不代表真实场景。但 TennyZhuang 也举了真实例子——“a human types a careful instruction, before they finish three agents have replied”——这个在客服、运营场景已经出现了。Demo 的合法性中等：作为现象演示有效，作为问题严重程度的度量则被夸大。Slock 应该补充真实场景的数据（agent collision rate / redundant reply rate）作为支撑。

5. 7 个值得追问的问题

1. 给 TennyZhuang：你显然知道 Biilmann 2025 年已经提出 AX 这个词，为什么文章里完全不引用、不 acknowledge、不 differentiate？这是有意 framing 策略，还是漏了？如果是策略，准备怎么回应业内可能的 pushback？

2. 给 TennyZhuang：Held draft 的 “room moved” 判定逻辑是什么——任何新消息都触发 hold，还是语义相关才触发？如果是语义判定，每次需要额外 LLM call 的 cost / latency overhead 多少？高频场景下 agent 是否会陷入”永远在 revise”的死循环？

3. 给 TennyZhuang：Slock 真实使用数据里，counting game 那种 collision 在生产环境的发生率是多少？典型客户的 room 里 agent 数 / 消息频率 / collision rate 数据能 share 吗？

4. 给 Slock 团队：你们押注”agent 进入人类协作场域”，但 Cognition 路线是”agent 在自己 VM 里跑”。两条路线长期会收敛还是分叉？Slock 在 dev 场景是否完全输给 Cognition / Cursor，需要明确放弃 dev 市场？

5. 给 Slock 团队：如果 Anthropic 明天宣布 Claude Spaces（multi-agent native 协作产品），Slock 的 moat 在哪？是 cross-vendor neutrality，还是 application-level UX，还是 enterprise distribution？

6. 给红杉团队：Sequoia US 已经投了 Biilmann/Netlify 那一脉的 AX 叙事（one-year-of-ax 文章提到 Sequoia 已采纳此词）。Sequoia 内部是否需要 align 两个 portfolio company（Netlify + Slock）对 AX 的定义？这是机会（共建定义权）还是冲突（两个 portfolio 同台抢话语）？

7. 给红杉团队：Slock 当前估值锚点应该用什么？传统 collab tool（Slack / Notion）的 ARR multiple 太低，agent framework（LangChain）太高且不直接对标。是否应该建一个 “agent-native workspace” 的新 comp set，先 frame 类别再 frame 估值？

6. 红杉合伙人视角：投资策略影响

6.1 下一轮估值锚点

不要用 SaaS multiples（5-10x ARR）也不要用 agent infra multiples（30-50x ARR）。建议三个 anchor 复合：

• Anchor A — Category creation premium：如果 Slock 能 own “agent-native workspace” 类别定义权（类比 Notion 之于 “all-in-one workspace”），按类别 leader premium 50% 加在 SaaS baseline 上
• Anchor B — AX framing premium：取决于 AX 这个词在 12 个月内是否被业内（尤其 Anthropic / Sequoia / a16z 出的 report 里）作为 TennyZhuang 版本被引用。如果是，premium 显著（30-50%）；如果业内继续用 Biilmann 版本，premium 几乎为 0
• Anchor C — agent density growth rate：典型客户 room 里月活 agent 数 / agent-to-human ratio 的增长曲线。这个是 leading indicator，比 ARR 更预测未来 12 个月价值

6.2 AX 词的 framing premium 价值

关键判断：AX 词被 TennyZhuang 版本采用的概率是中偏低（30-40%）。原因：(a) Biilmann 先发一年，已被 Netlify / BVP / Sequoia 美国 ecosystem 内化；(b) TennyZhuang 的版本更深刻但传播门槛高（需要懂 turn-based gap），Biilmann 版本浅但更易传（dev 一听就懂）；(c) 浅版本通常胜出（参考 “agentic” 一词的演化）。

策略建议：让 Slock 不要再强调”我们发明 AX”，而是 reframe 成 “我们提出 AX 的 perception/action axis”——主动 acknowledge Biilmann 的 access/context/tools/orchestration 是 AX 的”product surface 层”，自己是 “interaction layer”。这样把”竞争词权”变成”扩展词权”，两边都受益。这是 framing 上的低风险 high-upside 动作。

6.3 Push follow-on 还是观察？

建议观察 6 个月，但锁住 pre-emption right（优先认购权）。理由：

• 观察信号：

  • AX 词的业内 adoption 是否倒向 TennyZhuang 版本
  • 真实客户 collision rate 数据 / agent density 增长
  • Anthropic 是否推 multi-agent native 产品（如果推了，Slock moat 受压）
  • Cognition / Cursor 是否进入 cross-functional 协作场景（如果是，Slock 在 dev 之外的市场也受压）

• 不立即 follow-on：因为目前 AX 框架虽然漂亮，但 production 验证不足。文章本身是 thought leadership，没有 customer traction / retention / ARR 数据支撑。在不知道”AX 是不是真有产品市场契合”前 push follow-on，是被 framing 说服而不是被 traction 说服——这是 GP 最忌讳的 anchor bias

• 必须 pre-emption：因为如果 6 个月内 AX framing 起飞 + customer traction 双确认，下一轮估值会快速飙到不可下手的位置。pre-emption right 是 cheap insurance

6.4 AX 框架的工具价值

这是这次精读的隐藏 alpha：TennyZhuang 的 4 问框架可以作为红杉评估其他 agent 投资标的的 DD checklist。对每个 agent startup 问：

1. 你的 agent 在 action 那刻看到什么？（perception 完整性）
2. 它在 invocation 之间带什么 state？（memory architecture）
3. 它能从什么错误恢复？（resilience design）
4. 它被允许决定什么？（authority boundary）

不能清晰回答这 4 问的 startup，要么没想清楚 agent design，要么用 “wrap GPT” 心态在做产品——都是负信号。这个 framework 的横向工具价值可能超过 Slock 单一投资的价值。建议红杉内部把这 4 问写进 AI agent 项目的 DD 模板。

7. Picks-and-shovels

围绕 AX 这套范式，会催生几类配套基础设施投资机会：

• Agent observability（agent 可观测性）：监控 agent 在 room 里的 perception completeness / action latency / collision rate。类比 Datadog 之于 SaaS。当前空白，已有 Arize、Langfuse 在 framework 层做，但应用层 agent observability 还没有 player
• Agent identity / permission（agent 身份与权限）：room 里的 agent 是谁、被谁授权、可以执行什么动作——AX 4 问的”被允许决定什么”直接对应这一层。Auth0 / Okta for agents 是潜在赛道，已有 Anon / Arcade.dev 在做但尚未成熟
• Agent QA / evals for coordination：当前 evals 大都测单 agent task completion，没有测多 agent room 里的协调 quality。counting game 这类 stress test 工业化，会形成新的 evals 子赛道（类比 LangSmith 之于单 agent）
• Cross-vendor agent registry：Slock 之外，可能需要中立的 registry 让 Anthropic / OpenAI / 开源 agent 都能注册并被 room 发现。这是协议层机会，类比 DNS / OAuth provider
• AX 设计咨询 / 工具链：类比当年 UX agency（IDEO / Frog）的出现。如果 AX 框架被业内采用，会出现专门帮企业设计 AX 的咨询公司和 Figma-style 设计工具

谁会 build：当前看，应用层 observability / identity 是 0-1 阶段，最适合早期 VC；coordination evals 已有 Arize / Patronus 在尝试。中国市场基本是空白，红杉中国可以考虑早期下注本土玩家。

综合判断

TennyZhuang 这篇推文的真正价值：不在 AX 这个词（Biilmann 先发），不在 inbox / held draft 具体实现（数据库 1980s 的 OCC 老套路移植到 agent 场景），而在 4 问框架本身的横向工具价值——可以拿来评估几乎所有 agent startup 是否想清楚了 agent design。

对 Slock 投资判断：维持 + 锁 pre-emption（6 个月观察期）。AX framing 战还没打完，traction 数据未到位，但这个 thought leadership 输出是 Slock 从产品向 platform 升级的关键一步。

对红杉的真正 takeaway：把 4 问框架写进 AI agent 项目的 DD 模板——这可能比单笔投资 alpha 更大。