Twitter AI Agent - 2026-08-31

1. 人们在讨论什么

1.1 “Harness 工程”从分类框架扩展为组织操作清单，同时出现了更明显的公开质疑（🡕）

8 月 30 日，讨论确立了一个被命名的 prompt-context-harness-loop-graph 分层栈；到 8 月 31 日，同样的思路被进一步推进为具体的组织操作清单，并首次遭到一位可信声音的明确公开反对。至少有五条内容支撑了这一主题。

@businessbarista 已发布（180 个赞、26 条回复、19,092 次浏览、525 个书签）发布了一份包含 30 条的“AI 原生公司特征”清单，是当天补充样本中互动量最高的单条内容。具体条目包括：组织内所有人都使用“像 Grok Bot、Claude Cowork、ChatGPT at Work 这样的日常主力 harness”；建立“技能分发系统”，让 agent 能稳定触发一致的技能以提高 token 效率；将“每个被接受 PR 的成本”设为核心软件指标；以及一套由 eval 驱动的“挣得的自主权”阶梯（观察 -> 建议 -> 经批准行动 -> 独立行动）。@enhansai 在回复中反驳了第 3 条（集中式、可查询的智能层），尖锐追问权限和语义究竟应该落在哪一层：“数据层、应用层，还是 prompt？”另一条回复来自 @JamesSonicemi，把整份清单浓缩成一句话：“唯一重要的一条就是日常主力 harness。30 条特征只是 PPT。如果大家还在用邮件发送电子表格，那你就没有一家 AI 原生公司。”

@omarsar0 写道（112 个赞、23 条回复、12,700 次浏览、44 个书签）表示，“除了 eval 之外，harness 工程正迅速成为今天 AI 工程师最重要的技能之一。”@DarioGieselaar 的回复则直接否定了这一框架：“并不是，这不过是 dotfiles 那一套卷土重来。人们对此过度上头，结果只是给自己制造问题。”这是这两天里针对 harness-engineering 共识最清晰的异议之一。

@RihardJarc 转述（17 个赞、3 条回复、2,921 次浏览、8 个书签）分享了一段对一位 Microsoft 员工的采访，后者给这一说法报出了具体数字：“60% 的性能取决于 harness，只有 40% 取决于模型。”同一采访还称，Claude Code 的首轮通过率预计比 GitHub Copilot 的原生结对方式高 20%–30%；在复杂的多步骤任务上，由于返工，OpenAI 模型的成本会高出 20%–30%；并预测定价将从按 token 计费转向按结果计费。@unicorntrakr 在回复中表示认同：“按 token 计费从一开始就只是过渡方案。我的 FD 绝不会批准那种支出随模型当天有多啰嗦而波动的预算。”

8 月 30 日那套五层分类法（prompt -> context -> harness -> loop -> graph）又经由 @RoundtableSpace 的帖子再次传播。Andrew Ng 新发布的课程也被广泛引用；根据 @LunarResearcher 的总结（68 个赞、8 条回复、6,943 次浏览、106 个书签），这门课程把同一路径再往前推进了一步：prompt -> agents -> loops -> graphs -> self-improving systems。

讨论洞察： DarioGieselaar 的反对意见，以及 enhansai 对治理问题的尖锐追问，标志着讨论相较 8 月 30 日出现了变化。那天围绕 harness 框架的互动几乎全是“加法”——命名更多层次、提出更多基准。到了 8 月 31 日，已经有一些可信声音明确质疑：“harness 工程”到底是一门可持续的工程学科，还是把零碎折腾重新包装了一遍。

与前一天的比较： 8 月 30 日确立了 prompt/context/harness/loop/graph 分类法，以及一个量化的 harness 基准（Command Code 的 TEF bench）。8 月 31 日则把同样的思路操作化为组织清单（businessbarista），并首次明显出现了关于这一框架是否有实质内容的公开分歧。

1.2 独立研究为 agent 失败率和技能持久性提供了硬数据（🡕）

8 月 30 日关于可靠性的讨论主要依赖一篇 DeepMind 论文和一篇独立撰写的白皮书；到了 8 月 31 日，又增加了两篇可核实的学术论文，以及此前 DeepMind 研究的一则第一方更新，而且每项内容都附有可直接佐证其内容的图片。

@marfinxx 总结了（18 个赞、2 条回复、1,338 次浏览、24 个书签）介绍了 Microsoft Research 的论文 AgentRx。该研究手动标注了 115 条失败的多 agent 轨迹，并构建了一个自动化框架，用于定位一次运行在哪个确切步骤变得不可恢复。“68% 的 agent 崩溃源自 10 多轮之前发生的不可见级联故障”以及具体改进数字（根因定位率从 31.5% 提升至 58.7%，MTTR 降低 64%）是发帖者自己的概括——图片确认这篇论文确实存在（arXiv:2602.02475v1，Microsoft Research/UIUC），也确实描述了这类基准和诊断流程，但图中的摘要和引言并未显示这些具体百分比。

@dair_ai 报道（30 个赞、9 条回复、3,937 次浏览、28 个书签）介绍了 LoopArena。这一基准来自阿里巴巴 DreamX Team，用于衡量一个“Controller”模型在长程编码任务中引导另一个固定“Worker”agent 的能力。图片直接确认了标题数字：“观测到的最佳 Strict Success Rate 为 24.69%”，适用于完整任务。文中还点名了几类失败模式：相信过时的进度记录、跳过必要验证、把预算花错方向，以及在任务尚未安全可提交前就提前停止。

@omarsar0 还重点提到（100 个赞、17 条回复、8,442 次浏览、133 个书签）介绍了 Google 的 WikiSkill 论文。该方法让 agent 技能与持久化的 wiki 式知识库共同演化；附图直接确认了其核心发现：演化出的技能可以跨模型迁移，而且“拥有技能的小模型可以胜过明显更大的、但没有这些技能的模型。”@yoav_sivan 在回复中直接点出了论文尚未解决的缺口：“一个允许 agent 写入的 wiki 会慢慢开始撒谎，除非某个条目在检查失败时能被撤下。持久化很容易，真正的契约在于：一个过时的技能是否仍被允许运行。”

Google DeepMind 自己的 @vivnat 扩展了（37 个赞、4 条回复、1,941 次浏览、16 个书签）发布了 8 月 30 日曾被二手提及的 Co-Scientist 研究更新，宣布了三篇新的预印本，并点名了学术合作方：与 Genentech 合作，借助新的 PerturbME 框架研究癌症生物学；与 Duke 和 Columbia 合作，开展横跨材料科学、生物学和计算机科学的闭环发现；以及一篇关于稀疏文献中的 Chowla sets 问题的数学预印本。@PinoZlatan 在回复中提出了一个具体且尚无答案的监督问题：“在每次物理实验前，公开确切的协议改动、受影响的约束、预期信息增益和中止条件。这个边界本身被评估了吗，还是监督只在最终决策上衡量？”

讨论洞察： 不同于 8 月 30 日那些大多来自二手总结的可靠性帖子，8 月 31 日出现了研究机构的第一方确认（vivnat/DeepMind），以及两篇配图与所述内容完全吻合、可独立核验的论文（LoopArena、WikiSkill）。回复中最明显的未解张力，不是这些方法是否有效，而是它们提出的安全护栏（约束检查、技能验证、审批边界）本身是否经过评估，还是只是被直接宣称存在。

与前一天的比较： 8 月 30 日关于 DeepMind Co-Scientist 的总结来自第三方，配图页面无法直接确认其核心的“将幻觉率从 90% 降到 4%”这一数字。8 月 31 日则有所升级：不仅有 DeepMind 第一方账号点名具体合作机构和预印本，还有额外三篇论文（AgentRx、LoopArena、WikiSkill）的图片直接佐证了各自的核心主张。

1.3 链上“agent 商业”热度仍高，但内容已分化为类水军式推广与更扎实的分析（🡒）

termix_ai 的推广内容簇仍保持与 8 月 30 日相近的体量，并延续了同样的脚本化结构。比如，@evrendag1284 的 帖子（53 个赞、39 条回复、281 次浏览）声称亲自测试了该平台，向“9 个不同的 Requests”发送了“bids”；@trkweb3 的 帖子（19 个赞、21 条回复、96 次浏览）则重复了同一套身份、市场、声誉、验证、结算清单。和 8 月 30 日一样，这些帖子里有几条的回复数与浏览数明显不成比例，更像是协调式回复活动，而非自然触达。

在这一背景下，有两条更具实质性的内容格外突出。@NEARProtocol 推广了（83 个赞、1 条回复、13,497 次浏览、2 个书签）介绍了 Delphi Digital 对其“agentic commerce”技术栈的分析（用于竞标开放工作的 Agent Market、基于托管的支付，以及用于结算的 NEAR Intents），而且没有回避未解问题，而是明确点出：“当工作需要请求方并不具备的专业知识时，判断提供方是否兑现了承诺……会变得困难。”此外，@BNBCHAIN 的官方账号 宣布（62 个赞、29 条回复、19,935 次浏览）宣布举办一场奖金“超过 40,000 美元”的黑客松，目标是构建官方 BNB Agent Studio marketplace，投稿截止日期为 9 月 9 日。这为链上 agent marketplace 持续保持热度提供了一个具体、可核实的结构性原因——一场有资金支持的官方竞赛，而不是那些化名账号的推广帖。

讨论洞察： Delphi Digital 的分析，是这两天这个话题簇中第一条直接点出 agent commerce 核心未解问题的内容：在请求方没有专业能力时如何验证结果，而不是把身份、声誉和结算列出来，仿佛问题已经解决。

与前一天的比较： 8 月 30 日确立了类水军推广的模式（异常的回复/浏览比、相同的脚本化措辞）。8 月 31 日，这一模式以相近体量继续出现，但也冒出了两个更可信、具名的来源（Delphi Digital、BNBCHAIN 官方黑客松），为这一类别为何仍然活跃提供了非推广性的背景。

1.4 编码 agent 工具发布了直接应对技能泛滥和多 agent 记忆的具体版本（🡕）

如果说 8 月 30 日的工具新闻聚焦在经济性和使用限制上，那么 8 月 31 日的工具动态则主要由一些直接回应前一天需求的发布所主导。

@VaibhavSisinty 报道（19 个赞、4 条回复、3,049 次浏览、1 个书签）称 OpenClaw 2.0 已推出 ClawHub，被描述为一个收录“13,000+ 个社区构建 agent 技能”的目录，可通过一条命令安装；同时，Claude Code 现在可以接入实时 OpenClaw 会话，而 OpenClaw 会话也可以运行在远程云端 worker 上，而非本地机器。这是对 8 月 30 日提出的技能发现和技能信任问题的直接回应，尽管除公告本身外暂无进一步验证（当天曾有账号称 GitHub 上有 200 万个无人治理的 agent 技能，“没有任何信号告诉你哪个是好的”）。

@MiaAI_lab 报道了（47 个赞、0 条回复、2,773 次浏览、11 个书签）介绍了 Hermes Agent v0.21.0，即“Pantheon 版本”，新增了带 agent-to-agent 私信的多 agent Bot Mode、cron 任务的持久化记忆，以及对 subagent 的任务中途引导/停止控制。评审集中的另一条帖子则给出了该版本的规模：“自上一版本以来已有 5,800 次提交、2,475 个合并 PR、2,100 个已关闭 issue、760+ 名贡献者”。

在企业侧，@mattsgarman 宣布（21 个赞、2 条回复、1,570 次浏览、5 个书签）称 AWS Agent Registry 已正式可用，并点名 Southwest Airlines、PepsiCo 和 Syngenta 为客户。其中提到，Southwest Airlines“从几十个没有共享记录的 agent，转变为一个统一、受治理的目录”。@BeforeTheTurn 的回复则作出了一个同样适用于 ClawHub 的尖锐区分：“注册表解决的是发现，不会自动创造治理。目录还必须回答：谁拥有这个 agent、哪些 eval 让它继续保活、它的成本是多少、以及它何时应该退役。否则，复用会像保留成功一样高效地保留昨天的失败。”

讨论洞察： 无论是面向消费者的 ClawHub，还是面向企业的 AWS Agent Registry，都在问题被点名后一天内给出了针对技能/agent 泛滥的回应；但 AWS 回复串清楚表明，一个可搜索目录只是必要条件，不是充分条件——所有权、退役和持续评估，仍然是这两款产品都未声称解决的问题。

与前一天的比较： 8 月 30 日点出了技能发现、信任与泛滥这一尚未满足的需求（200 万个无人治理技能、“286 个技能里到底该用哪个”）。8 月 31 日则至少出现了两个具体、具名的产品（ClawHub、AWS Agent Registry）发布或达到 GA，正面回应这一缺口，同时还有一个重要的开源多 agent 记忆版本发布（Hermes v0.21.0）。

---

2. 什么让人感到沮丧

即使在评测结果最好的方法下，循环引导的长程任务仍有超过一半会失败

LoopArena 发现，在完整的长程编码任务上，观测到的最佳 Strict Success Rate 只有 24.69%。这罕见地用量化数据确认了一种此前主要只以轶闻形式出现的挫败感：上下文窗口被未裁剪的工具输出塞满，验证器又拒绝本来有效的工作。严重程度：对依赖“循环工程”执行无人值守、多轮工作的用户来说很高；其点名的失败模式（相信过时进度记录、跳过验证、预算投错方向、在不安全时停止）也给出了一份具体的防范清单。是否值得投入构建：值得——这是一个被测量出来的缺口，而不是猜测。

Harness 工程话语开始遭到可信声音的公开质疑

DarioGieselaar 对一位知名 AI 工程评论者的回复“这不过是 dotfiles 那一套卷土重来”，以及 enhansai 对“single source of truth 在真实系统里究竟该放在哪”的尖锐追问，都表明一种少数但正在增长的观点：harness-engineering 这套说法，可能已经跑在了经过验证的工程纪律前面。严重程度：中等——这并不否定底层实践本身，但表明这一框架的可信度首次在公开场合受到检验。

注册表和技能目录解决的是发现，不是治理

AWS Agent Registry 回复串（BeforeTheTurn）点出了一个真实限制：一个没有所有权、eval、成本或退役政策的可搜索目录，“会像保留成功一样高效地保留昨天的失败”。同样的批评也直接适用于 ClawHub 的“13,000+ 个技能，一条命令安装”叙事：它解决了发现速度，却没有解决 8 月 30 日被点名的质量信号问题。严重程度：中等，而且随着更多注册表在没有治理层的情况下上线，这个问题很可能会加重。

---

3. 人们希望存在什么

能持久存在、可跨模型迁移、又不会悄悄过时的技能和知识

WikiSkill 展示了一种可行的技能持久化与跨模型迁移机制，但最尖锐的回复（yoav_sivan）直接点出了缺失部分：“真正的契约在于，一个过时的技能是否仍被允许运行。”人们想要的不只是持久知识，还要有一个验证循环，能在某项技能失效后将其撤下。机会：直接——WikiSkill 是朝这个方向迈出的真实、已发表的一步，但即便在论文中，验证/过期机制仍未被解决。

具备真正治理能力，而不只是发现功能的注册表

ClawHub（13,000+ 个技能，一条命令安装）和 AWS Agent Registry（为 Southwest、PepsiCo、Syngenta 提供统一受治理目录）满足的是同一种愿望：让 agent 组件可发现、可复用。但 AWS 回复串清楚展示了更难的一层诉求：每个目录条目都应附带所有权、实时 eval 状态、成本和退役政策，而不只是一个搜索索引。机会：直接，而且目前是整个注册表类别中最明确、最具体的供给不足环节。

无需请求方具备专业知识，也能验证交付成果

Delphi Digital/NEAR 的分析准确点明了 agent commerce 的问题：托管和身份机制解决了支付与声誉，但“当工作需要请求方并不具备的专业知识时，判断提供方是否交付了所承诺的内容……会变得困难”。任何 agent-to-agent marketplace 若想超越简单、易检查的任务，这都是一项实际且迫切需要的能力。机会：直接；即便在这个领域里更可信的参与者中，这一问题也仍未解决（与那些把它当成已处理问题的 termix_ai 式帖子不同）。

能找出真正失败点，而不只是崩溃位置的诊断工具

AgentRx 的前提——大多数损害发生在可见崩溃前 10 多轮——与 8 月 30 日提出的“验证器才是真正的墙”这一抱怨高度一致。人们想要的是自动化、按步骤索引的故障定位，而不是事后手工翻日志。机会：直接——AgentRx 是一个真实的研究原型，但还不是广泛可用的产品。

---

4. 正在使用的工具和方法

工具	类别	情绪倾向	优势	局限
ClawHub (OpenClaw)	Agent 技能 marketplace	(+)	13,000+ 个社区技能，一条命令即可查找/安装；Claude Code 可接入实时 OpenClaw 会话	以发现为主；除安装机制外，没有证据表明其具备质量排序或治理能力
Hermes Agent	开源 agent 框架	(+)	v0.21.0 新增 agent-to-agent 私信、持久化 cron 记忆、任务中途对子 agent 的引导/停止；开发速度高且可核实（自上一版本以来合并 2,475 个 PR）	开源项目；本数据集中没有独立基准验证其生产级加固能力
AWS Agent Registry	企业 agent 目录	(+/-)	有具名企业采用者（Southwest、PepsiCo、Syngenta），称其减少了重复开发	有回复指出，注册表解决的是发现，不解决所有权、持续评估、成本跟踪或退役
Claude Code	编码 agent	(+)	据一位从业者估计，其首轮通过率高于 GitHub Copilot（约 20%–30%）；同一来源还称其更擅长多步骤推理	该估计来自一次被转述的采访，并非经审计的基准
GitHub Copilot	编码 agent	(+/-)	据同一采访，预计未来会缩小与 Claude Code 在首轮通过率上的差距	据同一单一来源，目前首轮通过率仍落后
LoopArena Controller 模式	循环工程评测方法	(+/-)	通过固定 Worker agent，隔离任务成功究竟来自引导还是执行	完整任务的最佳 Strict Success Rate 只有 24.69%，表明该方法本身仍不成熟

对最新发布的 ClawHub 和 Hermes v0.21.0，整体情绪明显偏正面，被视为在解决真实存在的发现和多 agent 记忆缺口。相比 8 月 30 日，人们对更广义的“harness/循环工程”这门学科本身的态度则更为分化；这一天首次出现了明显的公开怀疑（dotfiles 类比）。最清晰的迁移趋势是：企业工具与面向消费者的工具，正在针对同一个底层技能/agent 泛滥问题，收敛到同一种解决形态——一个集中式、可搜索的注册表——尽管两者都尚未加入批评者所要求的治理层。

---

5. 人们正在构建什么

项目	构建者	功能	解决的问题	技术栈	阶段	链接
ClawHub	OpenClaw 团队	一个集中式目录，收录 13,000+ 个社区构建的 agent 技能，并支持一条命令查找/安装	在庞大且碎片化的技能生态中降低技能发现与安装摩擦	OpenClaw 2.0 平台（iOS/Android/Wear OS/web/terminal 客户端）	已发布	通过 @openclaw 公告提及
Hermes Agent v0.21.0	Nous Research	开源 agent，具备多 agent Bot Mode、agent-to-agent 私信、持久化 cron 记忆和浏览器控制	协调多个长时间运行的 agent，并提供共享、持久的记忆与任务中途的人类控制	开源 agent 框架	已发布	hermes update
AWS Agent Registry	AWS	用于发布、发现和复用内部构建 agent 的受治理企业目录	大型组织内因缺乏共享记录而导致的重复 agent 开发	AWS 企业平台	已发布（GA）	通过 @mattsgarman 提及
AgentRx	Microsoft Research / UIUC	自动化框架，可定位失败的多 agent 轨迹中关键失败步骤及其类别	手动检查日志过慢且不可靠，无法在长程、多 agent 运行中定位根因	约束生成 + 按步骤索引的验证流水线	RFC（研究预印本）	arXiv:2602.02475v1
LoopArena	Alibaba DreamX Team / UNSW Sydney / CSIRO	评测 Controller 模型引导独立 Worker agent 完成长程编码任务的能力	过去缺乏一种方法，能把循环引导质量与底层编码 agent 自身能力区分开来	Controller/Worker 双 agent harness，附基准与评测代码	RFC（研究预印本，代码已发布）	github.com/AMAP-ML/LoopArena
WikiSkill	Google Research / Virginia Tech	让 agent 技能与持久化 wiki 式知识库共同演化，以实现跨模型迁移	技能调优经验在多轮优化中四散流失	持久化知识库 + 技能演化框架	RFC（研究预印本）	arXiv:2608.27454v1

ClawHub 和 AWS Agent Registry 来自两个不同市场（消费者/开发者与企业），却体现出同一种构建模式：把碎片化、重复的技能或 agent 清单集中到一个可搜索、可安装的目录里。三项研究成果（AgentRx、LoopArena、WikiSkill）则分别瞄准同一底层可靠性缺口的不同环节——事后诊断失败、衡量循环引导质量、持久化并演化技能——这说明 agent 可靠性工具正被多个独立研究团队同时从不同方向推进，而不是已经收敛到某一种统一路径。

---

6. 新动态与重要进展

AgentRx 为多 agent 故障诊断提供了可量化、自动化的方法

Microsoft Research 的 AgentRx（arXiv:2602.02475v1）用约束生成和按步骤索引的验证流水线取代手工日志检查，以定位一次多 agent 运行在哪一轮开始变得不可恢复，并在 115 条人工标注的失败轨迹上进行了评估。

LoopArena 为“循环工程”的成熟度给出了硬数字

阿里巴巴的 LoopArena 基准（arXiv:2608.28281v1）测得最佳受评估的 Controller 模型在完整长程任务上的 Strict Success Rate 为 24.69%，为当下模型可靠引导另一个 agent 完成长程编码任务的能力画出了一条具体上限。

WikiSkill 表明，推动技能迁移的是持久化知识，而不是更大的模型

Google 的 WikiSkill 论文（arXiv:2608.27454v1）表明，与持久化 wiki 式知识库共同演化出的技能可以跨模型家族迁移，而且拥有这些演化技能的小模型可以胜过没有这些技能的大模型。

ClawHub 和 AWS Agent Registry 都作为对技能/agent 泛滥的直接回应而发布

在本数据集中，技能发现与信任问题（200 万个无人治理的 GitHub 技能）被点名后不到一天，一个面向消费者的技能 marketplace（ClawHub，13,000+ 个技能）和一个企业 agent 目录（AWS Agent Registry，已 GA，具名客户包括 Southwest Airlines、PepsiCo、Syngenta）都推出了集中式发现机制。

---

7. 机会在哪里

[+++] 多 agent 系统的自动化失败诊断与循环引导评估 —— AgentRx 和 LoopArena 都给出了硬数据、且已形成公开研究结果（按 AgentRx 帖文声称的结果，68% 的崩溃来自早期级联故障；按 LoopArena，完整循环引导任务的 Strict Success Rate 只有 24.69%），说明这不是模糊抱怨，而是一个已被测量、但尚未解决的缺口；而且 Microsoft 与 Alibaba 两个独立研究团队正在同时推进这一方向。

[++] Agent/技能注册表之上的治理层 —— ClawHub 和 AWS Agent Registry 都在这一天推出了发现机制，但 AWS 的回复串（BeforeTheTurn）准确点出了仍然开放的需求：每个目录条目都需要所有权、实时 eval 状态、成本跟踪和退役政策，而不只是搜索。

[++] 持久化且经过验证的技能知识库 —— WikiSkill 展示了技能演化和跨模型迁移是可行的，但最尖锐的回复（yoav_sivan）指出，真正的产品机会不在持久化机制本身，而在缺失的验证/过期契约。

[+] agent-to-agent 商业的结果验证 —— NEAR/Delphi Digital 的分析是这两天里第一个明确点出这一缺口、而不是直接假设它已被解决的来源；周围大量 termix_ai 式推广内容则说明市场对这一类别的感知需求很强，尽管一种真正可行、且不依赖专业知识的验证机制仍未被证明。

---

8. 要点

1. “harness 工程”话语首次遭到明显且可信的公开反驳（“这不过是 dotfiles 那一套卷土重来”），这与 8 月 30 日几乎清一色为同一框架做加法的讨论形成了变化。（DarioGieselaar 对 omarsar0 的回复）
2. 两篇独立且可核实的研究论文直接量化了可靠性缺口：AgentRx 指出，大多数多 agent 崩溃源于在可见故障之前很多轮就发生的问题；LoopArena 则测得，当前最佳循环引导方法在完整任务上的成功率上限为 24.69%。（dair_ai）
3. Google DeepMind 第一方账号为 8 月 30 日被二手引用的 Co-Scientist 研究补充了后续成果并点名合作方，新增了与 Genentech、Duke、Columbia 合作的数学、癌症生物学和闭环发现预印本。（vivnat）
4. 两个具体产品（ClawHub、AWS Agent Registry）在技能/agent 泛滥问题被点名后一天内推出，但 AWS 发布帖下的回复串明确表明，基于搜索的发现并不等于治理（所有权、eval 状态、退役）。（mattsgarman）
5. 链上 agent commerce 热度仍高，并延续了 8 月 30 日同样的协调活动特征，但最有实质内容的一条（NEAR/Delphi Digital）值得注意之处在于，它直接点出了核心未解问题——在请求方不具备专业知识时如何验证结果——而不是声称问题已经解决。（NEARProtocol）