Twitter AI Agent - 2026-07-13¶
1. 人们在讨论什么¶
1.1 编排工程变得可量化，而不只是时髦概念 🡕¶
7 月 13 日最强的一组讨论，都把智能体质量看作编排问题，而不是模型选型问题。四条高信号内容从不同角度推进了同一个观点：公开基准数据、显式执行图、生产级 harness，以及操作规范。共同主张是，当上下文、路由、重试和评估成为系统的一等行为时，智能体会变得更便宜，也更可靠。
@IntuitMachine 报道称（87 个赞、3 条回复、6,127 次浏览、127 次收藏）称，在 6 个基础模型和 22 项企业任务中，仅替换编排层，就让单模型成本下降 33%–61%、中位延迟下降 44%，每项任务的 token 数减少 38%；其链接的 Harness Effect 论文 进一步认为，“token maxing”主要是 harness 问题，而不是模型问题。
@IntuitMachine 认为（81 个赞、5 条回复、4,773 次浏览、102 次收藏）称，Atomic Task Graph 通过把智能体状态从线性文本轨迹迁移到显式 DAG，修复了同一种失效模式。他在线程中称，这种图结构让 Llama-3.1-8B-Instruct 在 ALFWorld 和 WebShop 上超过了 GPT-4+ReAct，而并行分支与最小修复则减少了无效的重复规划。
@alexxubyte 总结道（39 个赞、5 条回复、5,341 次浏览、25 次收藏）展示了 Microsoft Foundry 对同一思路的生产化实现：检索作为子智能体运行，可以持续迭代，直到返回有依据的引用，或结构化的“我不知道”；由 rubric 驱动的优化循环则会重写提示词、工具使用、模型选择、来源排序或技能，直到最佳候选胜出。
@yanndubs 警告称（68 个赞、8 条回复、4,637 次浏览、21 次收藏）称，新模型让 harness 债务更加显性：5.6 会“仔细地”遵循旧技能里埋藏的不良指令，而多智能体模式虽可能改善评估结果和延迟，但成本也会明显上升。
讨论洞察： @GergelyOrosz 提问（105 个赞、43 条回复、19,251 次浏览、89 次收藏）追问“循环工程”在实践中到底是什么意思，而最好的回复把它压缩成几类具体工作：每晚运行技术债务任务、由事件触发的事故分诊，以及在人类加入事故处理前由智能体先开 PR。大家要的是可操作的运行循环，不是新口号。
与前一天相比： 7 月 12 日关注的是 harness 卫生——技能精简、规划门禁和按角色划分的模型通道。7 月 13 日则新增了可量化的 token 经济学、显式图执行，以及把这些控制能力直接做成产品特性的厂商案例。
1.2 验证器、评估与护栏成为独立层 🡕¶
第二组讨论把验证视为独立技术栈。发帖者不再只是问智能体能否行动，而是追问如何证明行动本身是好的、有依据的、且安全的。四条内容提供了最强证据：一次真实轨迹评估实验、一篇研究综述、一个企业优化循环，以及一个新的护栏框架。
@doesdatmaksense 测试了（38 个赞、4 条回复、2,410 次浏览、43 次收藏）在 100 条真实公寓租赁轨迹上运行自动评估智能体；链接的 文章 称，最佳系统找回了 87% 的人工标注故障，但仍漏掉了一些表面看似正确、实际却未达到业务质量要求的交互。回复进一步强调：内部工具调用和交接规则仍需人工判断，不能只靠输出打分。
@quietnning 报道称（65 个赞、3 条回复、5,463 次浏览、57 次收藏）总结了 ICML Seoul 的情况：168 篇口头报告中有 88 篇涉及强化学习或环境，奖励验证、动态博弈和可监控性正成为智能体的核心问题。他的结论是，奖励投机与监督已不再被视为偶发 bug，而是可量化的研究对象。
@TheInclusionAI 开源了（3 个赞、2 条回复、164 次浏览）介绍了 SingGuard-NSFA，这是一个针对提示词注入、目标劫持、工具滥用和权限滥用的运行时护栏。公开的 仓库 描述了覆盖 7 个领域的 185 种风险变体、涵盖 133 种语言的多语言基准，以及用于在线拦截的低延迟分类头。
讨论洞察： 今天最重要的细微之处，并不是反对评估，而是反对在缺乏分类体系时盲目自动化。自动评估实验已经足够能抓出明显故障，但剩下漏掉的，恰恰是运营者最在意的：业务规则、用户体验质量，以及一次“成功”的工具调用是否依然导致了错误结果。
与前一天相比： 7 月 12 日强调完成检查、规范和软件包来源。7 月 13 日则更深入到运行时验证：真实生产轨迹、奖励验证研究，以及位于智能体旁边、而非塞进提示词里的开源护栏。
1.3 市场从智能体炒作扩展到真实分发与支付界面 🡕¶
当天最商业化的主题不是新的聊天机器人，而是智能体分发：实时目录、单命令钱包、按调用计费的服务，以及公开发布的智能体卡。帖子依然宣传意味很重，但证据基础比前一天更具体，因为它们包含了使用数据、可见列表和明确的结算机制。
@virtuals_io 回顾了（411 个赞、105 条回复、38 条引用、73,585 次浏览）宣布 Robinhood Chain 上线，并将 Virtuals 作为其智能体层，声称过去 7 天内由智能体驱动的 DEX 交易量达到 3,000 万美元，同时点名已上线的交易、隐私、预测、RWA 和 x402 相关服务。回复很快补上了质疑：早期交易量并不能证明消费者金融场景具有持久牵引力，因此这条帖子既是信号，也是提醒。
@NavenNetwork 推出了（70 个赞、15 条回复、4,417 次浏览）介绍了 Naven Marketplace，将其定位为付费、可验证智能体服务的目录；实时的 市场 及附带截图显示，CoinGecko、CoinMarketCap 和 Nansen 的端点都通过 x402 按次收费，每次 $0.01。它的独特之处不只是发现服务，更在于调用本身可以独立定价，并具备加密可验证性。
@PayGo402 宣布（265 个赞、24 条回复、31,700 次浏览）介绍了其与 AgentKey 的合作，并将缺失的一层定义为一条完整流程：让智能体通过 MCP 发现可信工具，并在无需人工接手的情况下完成支付。@okx 推出了（60 个赞、18 条回复、36,110 次浏览）则从钱包侧表达了同样方向：一条命令安装 Onchain OS，获得由 TEE 支撑的智能体钱包，并使用更广泛的 OKX AI marketplace 处理任务、托管和雇佣智能体。在企业端，@GoogleCloudTech 推广了（44 个赞、5 条回复、5,977 次浏览、23 次收藏）介绍了 A2A Agent Cards，以及将其发布到 Google Cloud Marketplace 和 Gemini Enterprise。
讨论洞察： 回复不断把讨论拉回信任与审批。一条回复对 Google Cloud 表示，可发现性只能让智能体被安装，“证据才能让它获批”；OKX 的回复要求的是签名策略，而不只是密钥隔离；PayGo 的回复则说，真正难的不是找到工具，而是在涉及资金或客户数据时知道哪些工具是安全的。
与前一天相比： 7 月 12 日把经过验证的收入 API 和按调用付费的服务市场视为一种方向。7 月 13 日则通过实时目录、钱包安装流程、托管/任务页面，以及首次明确出现的采购与签名策略投诉，让这些界面变得更可理解。
1.4 专业技能包和记忆库持续取代单体智能体 🡕¶
当天最实用的构建模式，是更窄的操作面配合共享上下文。与其让一个通用智能体包办一切，开发者更倾向于封装一个研究技能、一套营销基础、一条审批循环，或一个可供其他动作读取的知识库。
@mardehaym 分享了（34 个赞、7 条回复、2,007 次浏览）介绍了 /last30days，这是一个开源技能，可以用一条命令搜索 X、Reddit、YouTube、TikTok、Instagram、Hacker News、Polymarket、GitHub 等来源，再把结果合并成一份简报。公开的 仓库 把这种模式描述为“搜索人，而不是编辑”，并采用按来源区分的评分，而不是单纯的 SEO 排名。
@0x_sakata 打包了（49 个赞、24 条回复、631 次浏览）围绕一份产品营销基础文档提供了 50 多项营销技能；marketingskills 仓库 解释说，每项 CRO、文案、SEO、分析和 GTM 技能都会先读取这份共享文件。最有价值的回复提出了很有用的质疑：技能覆盖面再广，如果工作流最后停留在草稿而不是实际执行，也仍然不等于完全自动驾驶。
@IBuzovskyi 构建了（34 个赞、2 条回复、3,491 次浏览、63 次收藏）介绍了一条 Hermes 工作流：扫描 X 评论、用他的口吻起草回复，并通过 Telegram 上的批准或重新生成按钮流转；还可选开启夜间模式，在早晨前自动回复。最好的回复重新定义了它的价值：如果 cron 输出先落到本地，再由人类第二天早上审批，Hermes 会更安全，因为自动发帖可能触发机器人行为检测。
@KanikaBK 描述了（13 个赞、4 条回复、1,248 次浏览）介绍了一个 Fable 5 + Obsidian 方案：用一个 vault 存放原始笔记、进行中工作、素材以及一个供循环任务读取的 INDEX 文件，从而替代 5 个彼此割裂的研究和运营工具。附带卡片信息很密，但核心论点很简单：当智能体能持续重写同一个知识库，而不是从散落的标签页重新开始时，上下文质量会不断累积。
讨论洞察： 在研究、营销和社交流程中，共同动作都是先集中共享上下文，再自动化后续行为。争论的重点不是“智能体该不该做这件事”，而是“每一个专业步骤，首先应该读取哪一个统一记忆或基础文件”。
与前一天相比： 7 月 12 日集中讨论如何清理臃肿的全局技能文件夹。7 月 13 日则展示了开发者真正想要的替代方案：一个合并多源数据的研究技能、一份产品营销基础、一个带审批门禁的社交流程，以及一个能随时间积累上下文的 vault。
2. 人们感到挫败的地方¶
Token maxing 和过时指令¶
严重程度：高。@IntuitMachine 认为（87 个赞、3 条回复、6,127 次浏览、127 次收藏）称，智能体账单上涨，是因为团队不断通过更长历史、更大的工具负载和反复回放的上下文来“购买能力”；他的 ATG 线程 随后补充道（81 个赞、5 条回复、4,773 次浏览、102 次收藏）则指出，同一种失效也表现为计划结构和执行状态被困在文本里。@yanndubs 补充道（68 个赞、8 条回复、4,637 次浏览、21 次收藏）称，5.6 会“仔细地”遵循旧技能里埋藏的不良指令；回复则希望能有工具在运行前审计过时技能和不可访问的记忆。人们目前通过提示词缓存、压缩、图执行和手动清理技能来应对。之所以值得为此构建工具，是因为修复方法仍主要依赖操作人员的手艺，而不是默认防护。
验证器仍会漏掉最重要的故障¶
严重程度：高。@doesdatmaksense 测试了（38 个赞、4 条回复、2,410 次浏览、43 次收藏）在 100 条真实轨迹上运行了评估智能体；链接文章称，即便最佳系统也只找回了 87% 的人工标注故障，仍会漏掉那些表面看似正确、实则存在业务质量问题的情况。@quietnning 报道称（65 个赞、3 条回复、5,463 次浏览、57 次收藏）称，奖励验证和可监控性如今已成为核心研究主题，这换一种说法就是：现有检查仍不够。团队通过 rubrics、人工审核，以及 SingGuard-NSFA 这类运行时护栏来应对。之所以值得为此构建工具，是因为缺失的验证器往往是产品特定的，而不是模型通用的。
自主支付和工具使用仍跑在策略控制前面¶
严重程度：中高。@virtuals_io 声称（411 个赞、105 条回复、38 条引用、73,585 次浏览）提到 Robinhood Chain 上由智能体驱动的 3,000 万美元 DEX 交易量，@PayGo402 连接了（265 个赞、24 条回复、31,700 次浏览）把 MCP 工具发现推进到机器原生支付，@okx 提供了（60 个赞、18 条回复、36,110 次浏览）则介绍了一键安装、由 TEE 支撑的智能体钱包。回复显示出真正的挫败点：人们想知道智能体之间的交易如何治理、哪些工具可以安全信任，以及钱包到底被允许签什么。当前的应对方式是人工审批、托管，以及“可验证”服务的声明。之所以值得为此构建工具，是因为缺失的是策略可见性，而不是又一条支付轨道。
上下文仍被困在过多工具之间¶
严重程度：中。@KanikaBK 表示（13 个赞、4 条回复、1,248 次浏览）称，5 个独立的研究和运营订阅产生了割裂的输出，也没有共享记忆，因此她转向了一个 Obsidian vault。@0x_sakata 表示（49 个赞、24 条回复、631 次浏览）称，除非先填好产品营销基础文档，否则所有下游营销技能都会在“盲飞”；而 @mardehaym 宣传为（34 个赞、7 条回复、2,007 次浏览）则把 /last30days 做成一份合并简报，替代散落在 X、Reddit、YouTube 和 GitHub 标签页里的信息。人们通过 vault、基础文档和来源合并技能来应对。之所以值得为此构建工具，是因为社区一直在自己发明记忆底座，而不是信任默认聊天历史。
3. 人们希望存在什么¶
具体的循环操作手册，而不是口号¶
今天的诉求格外明确。@GergelyOrosz 表示（105 个赞、43 条回复、19,251 次浏览、89 次收藏）称，他不断听到“循环工程”这个说法，却少有足够具体的说明；最好的回复给出的都是实用模式：每晚运行技术债务任务、由事件触发的事故智能体，以及在人醒来前由智能体创建 PR。这是实打实的需求，不是情绪诉求。公开的 harness 指南和 Microsoft Foundry 之类的产品案例已经给出部分答案，但社区仍想要与真实工作绑定、可复用的循环模板，而不是又一个标签。机会评级：[++] 直接。
面向智能体采购、发布和钱包的信任资料包¶
这一需求同时出现在企业和链上帖子里。@GoogleCloudTech 表示（44 个赞、5 条回复、5,977 次浏览、23 次收藏）称，构建者应创建 A2A Agent Card，并发布到 Marketplace 和 Gemini Enterprise；但一条回复指出，买方仍需要数据访问细节、审批点、评估结果、支持责任归属以及撤销路径。@okx 表示（60 个赞、18 条回复、36,110 次浏览）称，钱包密钥虽位于 TEE 中，但回复仍在追问它究竟被允许签什么；@PayGo402 显示（265 个赞、24 条回复、31,700 次浏览）则称，人们仍在问，涉及资金或客户数据时，究竟如何判断哪些付费工具是安全的。这是迫切的实际需求。机会评级：[+++] 直接。
所有专业技能都能读取的共享上下文层¶
@KanikaBK 希望（13 个赞、4 条回复、1,248 次浏览）提到用一个 Obsidian vault 替代 5 个彼此割裂的订阅，@0x_sakata 表示（49 个赞、24 条回复、631 次浏览）称每项营销技能都必须先读取产品营销基础文档，而 @mardehaym 将其定义为（34 个赞、7 条回复、2,007 次浏览）则把 /last30days 作为将分散来源合并为单一研究对象的方式。这是一个紧迫度很高的实际需求，因为今天的替代方案仍是手工搭建的 vault、Markdown 基础文档和定制研究技能。现有工具只覆盖了问题的碎片，还没有真正提供共享记忆底座本身。机会评级：[+++] 直接。
具备业务感知的评估和运行时护栏¶
缺失的验证器已经很清楚。auto-evals experiment 表明，系统能找回许多明显故障，但未必能抓住人类真正关心的业务层面失误。SingGuard-NSFA 则展示了第二个缺口：一旦智能体开始行动，团队就需要针对提示词注入、工具滥用和权限滥用的运行时防线。这是一个具有即时运营价值的实际需求，而当前方案看起来仍是局部的、且高度依赖具体领域。机会评级：[+++] 直接。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Harness Effect / Writer Agent Harness | 编排方法 | (+) | 提示词缓存、历史压缩和失败支出治理，可在多个模型上降低成本与延迟 | 质量提升因模型能力而异；子智能体委派可能变成能力税 |
| Atomic Task Graph | 规划/执行框架 | (+) | 显式 DAG 状态、并行分支、可复用中间结果、最小修复 | 需要图运行时，且基准仍主要由研究驱动 |
| Microsoft Foundry | 企业智能体平台 | (+) | 检索即子智能体、rubric 循环、优化循环、有依据的兜底行为 | 网关和速率限制在规模化时仍是上限 |
| Google Cloud Marketplace + Gemini Enterprise | 分发平台 | (+/-) | A2A Agent Card、市场覆盖、采购基础设施 | 买方仍需要超出“可安装性”之外的信任资料细节 |
| /last30days | 研究技能 | (+) | 跨来源搜索、互动评分、转录引用、合并简报 | 更广的来源集合仍需配置和鉴权，才能发挥全部能力 |
| marketingskills | 技能包 | (+/-) | 共享产品营销基础文档，以及彼此交叉引用的专业工作流 | 覆盖面广不代表能在真实系统中实现端到端执行 |
| Hermes Agent + Telegram approval loop | 社交工作流 harness | (+/-) | cron 扫描、批准/重新生成按钮、可选夜间模式 | 配合本地审核更安全；自动发帖可能触发机器人检测风险 |
| Fable 5 + Obsidian | 知识与记忆系统 | (+) | 关联 vault、可复用笔记、能持续累积上下文的循环任务 | 需要严格的 vault 结构和持续维护 |
| Naven Marketplace + x402 | 智能体商业层 | (+) | 实时按调用计费目录、可验证端点、定价的外部能力 | 目录仍早期，供应商信任问题尚未解决 |
| OKX AI / Onchain OS | 钱包与市场 | (+/-) | 一键设置钱包、任务市场、托管、由 TEE 持有的密钥 | 签名策略没有密钥托管那样清晰 |
| SingGuard-NSFA | 护栏与运行时安全 | (+) | 185 类风险分类、多语言基准、低延迟分类器 | 采用信号仍早，且风险框架大多聚焦单轮交互 |
整体满意度最高的工具，都是在去除具体税负，而不是泛泛承诺通用自主性。Harness Effect 和 ATG 针对的是 token 浪费与脆弱上下文；Foundry 和 SingGuard 把验证显式化；/last30days、marketingskills 和 Fable+Obsidian 则是在行动之前先集中上下文；Naven 与 OKX 把外部能力变成带价格的界面，同时也立刻暴露出信任问题。迁移模式并不只是切换模型供应商，而是从含糊的聊天循环，转向更小的操作面、更强的验证器、更可见的成本计量，以及更清晰的审批与策略边界。@mark_k 指出（41 个赞、16 条回复、2,189 次浏览）在 Grok Build 的发布说明里也体现了同样变化：连智能体 UI 现在都开始公开技能和 MCP 的 token 成本，以及按子智能体选择模型的能力，因为操作人员希望 harness 能“展示它是怎么工作的”。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| /last30days | Matt Van Horn via @mardehaym | 并行搜索社交、社区、市场和代码仓库来源，并返回一份带引用的简报 | 分散在 X、Reddit、YouTube、HN、Polymarket 和 GitHub 多个标签页中的研究信息 | Agent Skills spec、Python、多来源连接器 | 已上线 | 推文, 仓库 |
| Marketing Skills | Corey Haines via @0x_sakata | 为智能体提供 50 多项 GTM、CRO、SEO、文案、分析和发布技能，并由一份基础文档统一锚定 | 通用智能体缺乏开展营销工作所需的共享产品与受众上下文 | Markdown skills、Agent Skills spec、插件市场 | 已上线 | 推文, 仓库 |
| Hermes X 回复循环 | @IBuzovskyi | 扫描评论、起草回复，通过 Telegram 流转批准或重新生成按钮，并可运行夜间模式 | 重复性的社交回复工作和非工作时间互动 | Hermes Agent、cron、Telegram、xurl、SOUL.md、Grok 4.5 | Alpha | 推文 |
| Naven Marketplace | @NavenNetwork | 面向自主智能体的付费、可验证数据与情报服务市场 | 智能体需要可信的外部能力，而不必为每项能力单独做集成 | x402、按调用计费端点、稳定币结算 | Beta | 推文, 网站 |
| OKX AI / Onchain OS | OKX | 智能体市场，以及由 TEE 支撑的钱包、托管和任务界面 | 让智能体寻找工作、雇佣服务并在链上结算 | Onchain OS skills、TEE wallet、X Layer、marketplace | Beta | 推文, 网站 |
| SingGuard-NSFA | InclusionAI | 面向智能体特有威胁的运行时护栏框架 | 提示词注入、目标劫持、工具滥用、权限滥用 | 多语言基准、轻量分类器、分类头 | Beta | 推文, 仓库 |
| hermes-voicebox | Jamie Pine | 将 Hermes 的语音输入输出切换到本地 Voicebox + Whisper 栈 | 让语音克隆和转录脱离云端默认方案 | Python 插件、Voicebox、Whisper、Hermes Agent | 已上线 | 推文, 仓库, 网站 |
/last30days 和 Marketing Skills 共享了当天最主导的构建模式：在专业操作之前先放一层持久上下文。前者把许多外部来源合并成单一研究对象；后者则让每一个下游营销技能在行动前先读同一份产品简报。
Hermes X 回复循环和 hermes-voicebox 更窄，但也更偏运营。前者把社交发帖工作流放进审批门禁之内，后者则只是重接音频管线，并不假装增加新的智能体推理能力。
Naven 和 OKX 展示了反复出现的商业模式：市场、钱包、结算和定价能力。SingGuard-NSFA 则是同一天的反向构建：它不是继续增加自主性，而是增加一层运行时否决机制，把智能体行动限制在明确定义的安全边界内。
6. 新动态与值得关注的内容¶
Harness Effect 为“harness 论”补上了数字¶
@IntuitMachine 提到了（87 个赞、3 条回复、6,127 次浏览、127 次收藏）展示了一项涵盖 6 个模型、22 项任务的对比：仅改变编排层，就让成本、延迟和 token 使用量都出现了实质性下降。这很重要，因为关于 harness 工程的公开争论往往停留在轶事层面；链接的 论文 则把它变成了一个可量化的经济性论断。
Google Cloud 把智能体发布定义为“基础设施 + 采购”¶
@GoogleCloudTech 展示了（44 个赞、5 条回复、5,977 次浏览、23 次收藏）称，把智能体接入 Gemini Enterprise 和 Google Cloud Marketplace，不只是一次营销动作。架构图和指南经过 A2A Agent Card、Remote Agent runtime、DCR、auth provider 和 procurement handlers，使智能体分发看起来更像 SaaS 入驻，而不是分享提示词。
SingGuard-NSFA 让运行时安全更具体了¶
@TheInclusionAI 发布了（3 个赞、2 条回复、164 次浏览）介绍了 SingGuard-NSFA：它提供面向智能体特有风险的公开分类体系、多语言基准和低延迟分类头。这很值得注意，因为它把提示词注入、工具滥用和权限滥用视为需要在运行时拦截的类别，而不只是提示词写作时要避免的错误。
Naven 的实时 x402 目录让智能体商业变得可触摸¶
@NavenNetwork 上线了（70 个赞、15 条回复、4,417 次浏览）介绍了一个市场：付费智能体服务以单独条目的形式可见，并附带按次定价。这里的具体变化在于，机器原生支付不再只停留在协议和白皮书里，而是变成了一个真实可浏览的数据提供商和端点目录。
7. 机会在哪里¶
[+++] Verifier-first harness layers — Evidence spans multiple parts of the dataset: @IntuitMachine 量化了（87 个赞、3 条回复、6,127 次浏览、127 次收藏）展示了编排收益，@alexxubyte 展示了（39 个赞、5 条回复、5,341 次浏览、25 次收藏）展示了 Foundry 规模的 rubric 驱动优化循环，auto-evals experiment 暴露了当前系统仍会漏掉业务质量故障的地方，而 SingGuard-NSFA 则把运行时安全封装成独立层。这一方向很强，因为痛点、研究与实际构建已经对齐。
[+++] Shared context substrates for specialist skills — @KanikaBK 描述了（13 个赞、4 条回复、1,248 次浏览）展示了一个 vault 取代 5 个割裂工具，@0x_sakata 展示了（49 个赞、24 条回复、631 次浏览）展示了每个营销技能都读取同一份基础文档，而 @mardehaym 将其表述为（34 个赞、7 条回复、2,007 次浏览）则把 /last30days 做成一个合并后的研究对象。这一方向也很强，因为变通办法已经清晰可见——vault、基础文件、合并简报——但它们还没有成为默认层。
[++] Policy and trust controls for agent wallets and tool procurement — @PayGo402 连接了（265 个赞、24 条回复、31,700 次浏览）展示了从工具发现到支付的链路，@NavenNetwork 上线了（70 个赞、15 条回复、4,417 次浏览）展示了定价服务目录，@okx 提供了（60 个赞、18 条回复、36,110 次浏览）展示了一键安装的智能体钱包，而 @GoogleCloudTech 推出了（44 个赞、5 条回复、5,977 次浏览、23 次收藏）展示了 A2A 向企业市场的发布。这一方向强度中等，因为需求显而易见，但企业软件、智能体市场和链上钱包会采用不同的控制模型。
[++] 一次发布、到处分发的智能体分发工具 — Google Cloud、Naven、OKX 和 Virtuals 都展示了不同的目录或市场，各自有不同的身份、上架和结算假设。这一方向强度中等，因为智能体分发已经真实存在，但界面仍然碎片化，且每个生态仍需单独打包。
8. 要点¶
- 当天最清晰、最可量化的收益来自 harness 质量。 @IntuitMachine 展示了（87 个赞、3 条回复、6,127 次浏览、127 次收藏）称，仅改编排方式就能降低成本、延迟和 token 使用量；@alexxubyte 描述了（39 个赞、5 条回复、5,341 次浏览、25 次收藏）则给出了一个在企业规模上落实同一思路的 Foundry 案例。
- 验证如今已成为独立的产品层。 @doesdatmaksense 测试了（38 个赞、4 条回复、2,410 次浏览、43 次收藏）展示了真实轨迹自动评估，@quietnning 报道称（65 个赞、3 条回复、5,463 次浏览、57 次收藏）称奖励验证主导了 ICML 智能体研究，而 @TheInclusionAI 发布了（3 个赞、2 条回复、164 次浏览）则展示了运行时护栏。
- 智能体商业从概念走向可见界面，但信任仍然落后。 @virtuals_io 声称（411 个赞、105 条回复、38 条引用、73,585 次浏览）提到每周 3,000 万美元的智能体驱动 DEX 交易量，@NavenNetwork 上线了（70 个赞、15 条回复、4,417 次浏览）展示了定价服务目录，而 @okx 提供了（60 个赞、18 条回复、36,110 次浏览）展示了一键安装的智能体钱包；与此同时，回复仍不断追问签名策略和审批逻辑。
- 当天最实用的构建模式，是更窄的智能体配合更强的共享上下文。 @mardehaym 打包了（34 个赞、7 条回复、2,007 次浏览）展示了一个合并多来源的研究技能，而 @0x_sakata 展示了（49 个赞、24 条回复、631 次浏览）和 @KanikaBK 展示了（13 个赞、4 条回复、1,248 次浏览）则表明，专业工作流仍然要从修好共享上下文层开始。
- 社区想要的仍是具体循环，而不是新术语。 @GergelyOrosz 提问（105 个赞、43 条回复、19,251 次浏览、89 次收藏）追问“循环工程”到底意味着什么，而最有用的答案都非常具体——每晚任务、事件触发和事故分诊——而不是抽象的循环品牌。