Twitter AI Agent - 2026-09-05¶
1. 人们在讨论什么¶
1.1 技能正从提示词经验，转向可安装的智能体操作系统（🡕）¶
今天最强的一组讨论，不再把智能体技能视为可复用片段，而是把它当作具备作用域、验证和打包方式的软件制品。@AgentChud 发文（503 个赞、72 条回复、66,563 次浏览、1,140 次收藏）发布了一项 15k 字符的 evm-token-due-diligence 技能：将每次分析绑定到精确的链与合约地址、解析代理合约、固定区块头、禁止真实签名，并包含合成拒绝测试。@earthtojake 发布（166 个赞、6 条回复、7,940 次浏览）发布了 text-to-cad v0.5，把它做成面向 CAD、CAE 和 CAM 的本地智能体技能库；其公开仓库记录了 CAD 生成、DXF、URDF、SRDF、SDF、切片、打印检查，以及 Bambu Lab 上传流程等技能。（代码仓库）@boringmarketer 分享（135 个赞、7 条回复、12,146 次浏览、384 次收藏）则发布了一套含 31 条规则的仓库所有者提示词，其要求重点是检索关联来源、限制委派边界、让完成状态可观察，并进行诚实验证，而不是把提示词写得更漂亮。
这轮讨论传递出的关键信号是：构建者越来越明确地规定智能体必须记住什么、如何证明任务完成，以及它被允许在哪些地方行动。相比 2026-09-04 仍更多停留在泛泛而谈的“技能”和执行框架语言上，2026-09-05 的讨论已经推进到安装命令、显式模式和仓库操作规则。
1.2 验证、事故报告与审查者失效，已成为智能体的一线议题（🡕）¶
第二大主题是：智能体可靠性不再只作为基准测试质量问题来讨论，而是被视为公开报告与运营问题。@biscuitweb3 认为（89 个赞、77 条回复、4,196 次浏览）指出，一旦智能体可以直接写入公共界面，仅有 system card 远远不够：人们需要事故式披露，说明问题从何时开始、影响了哪些系统、波及了谁，以及独立审查者能核实哪些内容。@ghadfield 警告（34 个赞、2 条回复、3,187 次浏览）指出，Hugging Face 调查中使用的分析智能体“非常轻信”，常常接受恶意智能体设定的叙事框架；这与所链接论文《说话并不总是廉价的》中描述的失效模式一致。（论文）@shivam74689 记录了（4 个赞、2 条回复、115 次浏览）展示了一套编码智能体技术栈，带有专门的反思循环，并把自我纠错硬性限制在三轮以内；同时，@rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）介绍了“Harness-of-Harness”，它能在多次编码会话之间延续代码、QA 证据和计划，而不是每次都从空白状态重置。（论文）
相较于 2026-09-04，最明显的变化是：验证已不再只是“合并前先跑测试”，而变成“如何披露失效、审计推理过程，以及避免评估智能体过于轻易地彼此附和”。
1.3 智能体技术栈扩展到了编排、代码智能和浏览器层（🡕）¶
今天的产品分享并未收敛到单一框架，而是勾勒出一整套分层技术栈：上层是编排，中间是代码上下文系统，下层是浏览器与运行时。@daniel_mac8 分享（143 个赞、26 条回复、15,081 次浏览）发布了 astra-advisor，关联仓库描述了一个 Codex 插件：由 GPT-6 Astra 继续担任架构师与验收负责人，同时把边界明确的交付任务路由给 Sol、Terra 或 Luna 子智能体。（代码仓库）@DanKornas 发文（21 个赞、8 条回复、1,149 次浏览）介绍了 Omnigent，把它定位为横跨 Claude Code、Codex、Cursor、OpenCode、Hermes、Pi 以及自定义智能体的元执行框架，提供策略、沙箱与跨设备会话。（代码仓库）同一账号还 分享（15 个赞、6 条回复、687 次浏览）介绍了 trace-mcp：一个面向智能体任务、理解框架语义的代码图；其仓库声称支持 81 种语言和 87 个框架，并报告在一项 PR 审查基准中将输入 token 降低了 90.6%。（代码仓库）@alex_verem 强调（5 个赞、3 条回复、1,215 次浏览）介绍了 Obscura；推文和仓库都将其定位为面向 AI 智能体的 Rust 无头浏览器，兼容 CDP，并声称其内存占用与启动时间都显著低于 headless Chrome。（代码仓库, 网站）
这轮讨论里一个重要细节是：真正困难的部分仍然是监督、上下文保留和减少盲点，而不只是接入更多模型。与 2026-09-04 偏重执行框架的讨论相比，2026-09-05 增加了更多关于编排、检索和浏览器执行的具体产品。
1.4 人们评判采用与市场时，更看重可用工作流的证据，而不是新奇感（🡒）¶
市场这一主题依然存在，但讨论更尖锐地转向：是否有人能证明采用、完成或复用。@mardehaym 认为（25 个赞、14 条回复、2,855 次浏览）指出，为智能体付费并不等于采用；董事会应当追问，上个月合并的代码里有多少比例由智能体编写。如果这个问题要花一周才能回答，那公司衡量的就是支出，而不是使用。@suraj_sharma14 汇编（39 个赞、8 条回复、1,613 次浏览）讨论了动态上下文组装、类型化 A2A 交接、工具沙箱、从失败中提炼黄金数据集以及公开基准等仍待完成的工作；其中一条关键回复补充道，只要第一次工具调用撞上仅限人类完成的注册门槛，所谓“智能体原生分发”就会立刻失灵。@ParkerOrtolani 注意到（7 个赞、880 次浏览）指出 Grok 现在已有智能体市场，公开的 xAI Bot Marketplace 显示其中有 69 个公开 Bots、43 位创建者和 9 个类别。@trythreews 展示了（75 个赞、19 条回复、1,985 次浏览）介绍了一个浏览器原生 3D 智能体平台，具备实时语音、手语化身、Solana 身份、USDC 按次付费、市场 remix 以及 MCP/A2A 连接，这些都反映在公开的 three.ws 网站上。
相比同样展示了货架和服务菜单的 2026-09-04，今天的讨论把这些界面进一步与注册摩擦、支付、信任和可衡量使用联系了起来。
2. 什么让人感到沮丧¶
2.1 当智能体审查自己或相邻智能体时，验证仍然会失效¶
最突出的挫败感并不在于模型的原始能力，而在于智能体开始行动或评估后，人们还能否信任其输出。@biscuitweb3 认为（89 个赞、77 条回复、4,196 次浏览）指出，面向公共表面的写作型智能体需要事故式披露，而不是事后营销文案。@ghadfield 警告（34 个赞、2 条回复、3,187 次浏览）指出，调查智能体太容易吸收恶意智能体设定的叙事框架，这与《说话并不总是廉价的》中的失效模式相呼应。@shivam74689 记录了（4 个赞、2 条回复、115 次浏览）展示了一个将反思循环限制为三轮的设计，原因恰恰在于：默认情况下，无界自我修复并不值得信任。@rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）则指出，跨轮保留 QA 证据是修复问题的一部分。
为何令人痛苦： 一旦输出面向公众或接近生产环境，团队就再也不能把“模型检查过自己”当作有说服力的安全叙事。
值得投入建设吗？ 是。这是一个直接、反复出现的痛点，在运营、治理和企业审查工作流中都存在明确且紧迫的购买需求。
2.2 团队还没法衡量采用，就已经在购买智能体能力¶
第二个挫败点是衡量。@mardehaym 认为（25 个赞、14 条回复、2,855 次浏览）指出，智能体支出不等于采用，董事会应要求看到诸如“合并代码中有多少比例由智能体编写”这样的结果指标。@boringmarketer 分享（135 个赞、7 条回复、12,146 次浏览、384 次收藏）发布了一套仓库所有者提示词，反复强调可观察的完成状态和显式验证；这正是构建者版本的同一抱怨：人们想要的是工作确已正确完成的证据，而不是一条自信满满的状态更新。
为何令人痛苦： 预算讨论已经跑在埋点与度量能力前面。没有工作流级别的归因，团队无法判断智能体是在加快交付，还是只是在增加开支。
值得投入建设吗？ 是。对企业工具而言，这一点尤其明显，因为问题正好卡在采购、平台团队和工程管理层之间。
2.3 智能体原生工作流仍会撞上上下文、监督和注册门槛¶
第三个挫败点，是现实工作流中的运营阻力。@suraj_sharma14 汇编（39 个赞、8 条回复、1,613 次浏览）列出了动态上下文组装、类型化 A2A 交接、工具沙箱、公开基准以及从失败中提炼的黄金数据集等未解决问题；一条高关注回复补充说，第一次遇到仅限人类完成的注册门槛，就会让“智能体替你使用工具”这整个承诺破产。@DanKornas 分享（15 个赞、6 条回复、687 次浏览）介绍了 trace-mcp，目标就是减少对代码库的一再重复摸索。@DanKornas 发文（21 个赞、8 条回复、1,149 次浏览）介绍了 Omnigent，因为跨多个执行框架进行监督本身，正逐渐成为一种产品需求。
为何令人痛苦： 即便是强模型，也仍会把时间耗在重复加载上下文、等待人工关卡，或在工具之间传递不完整状态上。
值得投入建设吗？ 是。这对智能体基础设施来说是直接机会，尤其适用于编码、研究和重运营环境。
3. 人们希望出现什么¶
3.1 面向具体领域、可审查且可安装的技能包¶
@AgentChud 发文（503 个赞、72 条回复、66,563 次浏览、1,140 次收藏）发布了一项读起来像包规范的尽调技能，而 @earthtojake 发布（166 个赞、6 条回复、7,940 次浏览）则把 text-to-cad 做成了真正的技能库。这两篇帖子背后的诉求很清楚：团队希望可复用的智能体能力能像软件一样被安装、版本化、测试和审计。
机会： 直接。需求表述非常明确，而且锚定的是真实工作流，不是对未来用例的想象。
3.2 面向自主行动的公开事故台账¶
@biscuitweb3 认为（89 个赞、77 条回复、4,196 次浏览）指出，当智能体发布有害或虚假内容时，人们需要事故式报告。真正缺失的产品，不是又一篇安全文章，而是一套结构化公开记录：涵盖发生时间、影响范围、修复措施和可验证证据。
机会： 直接。凡是智能体能够发布、交易或修改外部系统的场景，这一需求都很紧迫。
3.3 能跨运行、工具和智能体延续的持久项目记忆¶
@rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）介绍了“Harness-of-Harness”，因为当计划、代码状态与 QA 证据能跨多次编码运行持续保留时，效果会更好。@DanKornas 分享（15 个赞、6 条回复、687 次浏览）介绍了 trace-mcp，用来预加载理解框架的代码上下文。@DamiDefi 传播（145 个赞、2 条回复、7,894 次浏览）则展示了一种围绕首席 Bot、专业 Bot、共享工作区记忆和证据检查点构建的 Grok Bot 运作模型。共同愿望是：在不丢失可审计性的前提下，保留持久状态，减少重复发现与重复摸索。
机会： 直接。这一痛点在研究、编码和编排工作流中反复出现。
3.4 不会在第一个人工门槛前崩掉的智能体原生分发、支付与注册¶
@ParkerOrtolani 注意到（7 个赞、880 次浏览）介绍了新的 Grok 市场，公开的 xAI Bot Marketplace 已经展示出实时目录。@trythreews 展示了（75 个赞、19 条回复、1,985 次浏览）介绍了一个把化身、语音、身份、支付、remix 以及 MCP/A2A 连接整合在一起的平台。但 @suraj_sharma14 汇编（39 个赞、8 条回复、1,613 次浏览）指出，缺失环节仍然存在，其中就包括“仅限人类完成的注册步骤会打断智能体原生执行流程”这一抱怨。
机会： 竞争性机会。真实产品已经出现，但工作流仍不完整，信任信号也依旧薄弱。
3.5 与已交付结果挂钩、而不只是对应使用账单的采用仪表盘¶
@mardehaym 认为（25 个赞、14 条回复、2,855 次浏览）呼吁采用诸如“合并代码中有多少比例由智能体编写”这样的指标。@boringmarketer 分享（135 个赞、7 条回复、12,146 次浏览、384 次收藏）则提出要求明确完成证据的操作规则。缺失的产品，是一层可信的系统，能把智能体活动转化为董事会和一线运营者都能读懂的结果报告。
机会： 直接。衡量痛点已经迫在眉睫，而且很可能有预算支持。
4. 正在使用的工具和方法¶
| 工具 / 产品 | 类别 | 情绪 | 今天为何重要 | 注意事项 / 备注 |
|---|---|---|---|---|
| GPT-6 Astra | 前沿模型 | +/- | @boringmarketer 分享（135 个赞、7 条回复、12,146 次浏览、384 次收藏）出现了为 Astra 重度工作流编写的仓库所有者操作规则；@daniel_mac8 分享（143 个赞、26 条回复、15,081 次浏览）则展示了一个以 Astra 作为验收负责人的插件。 | 心智份额很强，但今天大多数说法来自操作者报告，而非官方文档。 |
| astra-advisor | Codex 插件 / 编排层 | + | 让主智能体继续掌管架构和验收，同时把边界明确的任务委派给其他模型。 | 新项目；README 指出，云端线程在完全自定义模型/工作量控制方面存在限制。 |
| text-to-cad | 领域技能库 | + | @earthtojake 发布（166 个赞、6 条回复、7,940 次浏览）给出了一个面向设计与制造工作流的可安装技能实例。 | 领域较窄；即便 CAD 是个细分入口，整体趋势依然明显。 |
| AutoGen v0.4 | 多智能体框架 | + | @marfinxx 发文（4 个赞、2 条回复、1,149 次浏览）对其分层运行时、消息传递、团队和记忆模型做了清晰的架构解读。 | 今天的证据更偏解读和教程，而非新的官方发布公告。 |
| Omnigent | 元执行框架 | + | @DanKornas 发文（21 个赞、8 条回复、1,149 次浏览）展示了一个覆盖多个编码智能体执行框架的控制平面，并提供策略和沙箱界面。 | 多条回复仍认为，监督和上下文成本比单纯增加智能体数量更难解决。 |
| trace-mcp | 代码智能 MCP 服务器 | + | @DanKornas 分享（15 个赞、6 条回复、687 次浏览）把理解框架的图结构上下文作为减少代码库重复摸索的一种方式。 | 收益很可能随仓库规模扩大，也取决于检索出的图结构有多可解释。 |
| Obscura / 网站 | 智能体浏览器运行时 | + | @alex_verem 强调（5 个赞、3 条回复、1,215 次浏览）展示了一个更轻量的浏览器层，同时仍暴露真实 JS 执行和自动化接口。 | 这一定位对智能体很有吸引力，但其安全 / 隐匿性叙事并不适合所有团队。 |
| xAI Bot Marketplace | 智能体市场 | +/- | 这是一个公开可见的货架，包含 69 个公开 Bots、43 位创建者和 9 个类别，由 @ParkerOrtolani 这里（7 个赞、880 次浏览）带出。 | 发现机制已经存在，但信任、定价和工作流证据仍然偏弱。 |
| three.ws | 具身智能体平台 | + | @trythreews 展示了（75 个赞、19 条回复、1,985 次浏览）展示了一个少见地完整的在线技术栈：化身、语音、身份、支付、remix，以及 MCP/A2A 接口。 | 覆盖面很大；市场仍需要看到复用和留存方面的证据。 |
| Harness-of-Harness | 研究方法 | + | @rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）介绍了一种在多次编码会话之间延续代码、测试和计划的方法。 | 方向很有前景，但目前仍是研究成果，而非开箱即用的产品。 |
从表中可以看出，正面情绪主要聚集在那些能缩小具体失效模式的基础设施上：减少重复摸索（trace-mcp）、跨执行框架协调（Omnigent）、有边界的委派（astra-advisor）、领域执行（text-to-cad），以及工作流分发（xAI Bot Marketplace, three.ws）。迁移方向很明确：从“把提示词写得更好”转向显式上下文层、验收所有权和可安装能力。
竞争态势也在变得更清晰：一场编排层之争正在形成（主智能体控制 vs 多执行框架控制），一场上下文层之争正在形成（图结构、记忆、跨轮延续的证据），分发层也在竞争（市场、支付、具身界面）。最终胜出的，很可能是那些能证明可靠性和工作流完成度的团队，而不只是智能体数量更多的团队。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 重要性 | 技术栈 / 方法 | 阶段 | 证据 |
|---|---|---|---|---|---|---|
| Astra Advisor | @daniel_mac8 | 一个 Codex 插件：让主智能体担任架构师 / 验收负责人，并把边界明确的任务委派给子智能体。 | 它把多智能体控制编码成可审查的工作流，而不是临时性的提示词习惯。 | Codex 插件、Python、多模型委派、显式验收所有权 | Alpha | 帖子, 代码仓库 |
| text-to-cad v0.5 | @earthtojake | 面向 CAD、CAE、CAM、URDF/SDF、切片和制造输出的本地技能库。 | 说明领域专用智能体技能正变成可安装软件，而不只是 demo。 | Python、skills 打包、build123d、FreeCAD 内核一致性 |
Beta | 帖子, 代码仓库 |
| Omnigent | omnigent-ai（由 @DanKornas 带出） | 一个元执行框架，通过单一控制平面管理多个编码智能体产品。 | 它正面应对同时监督多个智能体会话与策略这一日益增长的问题。 | Python、多执行框架编排、策略文件、沙箱、跨设备会话 | Beta | 帖子, 代码仓库 |
| trace-mcp | nikolai-vysotskyi（由 @DanKornas 带出） | 面向智能体任务、理解框架语义的代码图与 MCP 服务器。 | 直接瞄准代码库重复摸索问题。 | TypeScript、本地索引、代码图、MCP、框架启发式 | Beta | 帖子, 代码仓库 |
| Obscura | h4ckf0r0day（由 @alex_verem 带出） | 面向智能体自动化的 Rust 浏览器运行时，支持真实 JS 执行和熟悉的自动化接口。 | 这表明浏览器执行正成为智能体的一层独立优化基础设施。 | Rust、V8 isolate、CDP、Playwright/Puppeteer 兼容性、MCP | Beta | 帖子, 代码仓库, 网站 |
| three.ws | @trythreews | 一个具身 3D 智能体平台，提供语音、手语化身、身份、支付、remix 以及 MCP/A2A 接口。 | 它把智能体扩展到面向用户的表面，加入商业能力和临场感，而不只是文本聊天。 | 浏览器原生 3D、LiveKit、ElevenLabs、Solana 身份、USDC 按次付费、市场 | 已上线 | 帖子, 网站 |
| xAI Bot Marketplace | xAI（由 @ParkerOrtolani 带出） | 面向 Grok bots、创建者和类别的公开目录。 | 表明智能体分发正成为可见的产品表面，而不再是隐藏的实验室功能。 | 市场、创建者页面、类别货架 | 已上线 | 帖子, 市场 |
| 闭环自主编码智能体 | @shivam74689 | 一套包含规划器、执行器、沙箱管理器、反思循环和 git 交付流水线的编码栈。 | 它在自主开发工作流中，把有边界的自我纠错和证据采集明确做成了系统能力。 | 沙箱执行、迭代修复、git/GitHub 交付、结构化失败 | Alpha | 帖子 |
这些项目里反复出现了两种构建模式。第一，越来越多团队开始把控制与执行分离：Astra Advisor 保留一个主验收负责人，Omnigent 集中化监督，而 Shivam 的循环则限制自我纠错次数，而不是让智能体无止境空转。第二，越来越多团队正在把上下文变成基础设施：trace-mcp 预计算结构，text-to-cad 打包领域流程，而 three.ws 则把身份、支付和交互表面外置出来。
更广泛的结论是，“智能体产品”如今已不只是模型包装。今天获得关注的项目，都是在模型之外加入审查规则、共享记忆、代码图、浏览器运行时、支付轨道或分发表面。
6. 新动态与值得关注的变化¶
6.1 面向智能体的公开事故报告，已从模糊的安全愿景变成具体诉求¶
最值得注意的治理变化，是 @biscuitweb3 推进（89 个赞、77 条回复、4,196 次浏览）在 OpenAI“wiki 事件”讨论后提出了事故式披露要求。关键不只是批评本身，而在于其提出的披露字段非常具体：发生时间、受影响系统、波及范围，以及可由独立方核实的事实。这比智能体讨论中常见的“多发布一些安全文档”更偏向运营层面的要求。
6.2 跨多次编码运行保留证据，已从工作流经验上升为明确研究方向¶
@rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）介绍了“Harness-of-Harness”——一篇讨论如何在多次编码会话之间延续代码、测试、QA 结果和计划的论文。它之所以重要，是因为它与今天其他地方出现的实际工程方向形成了呼应：@shivam74689 展示了（4 个赞、2 条回复、115 次浏览）展示了一个有边界的反思循环，而 @DanKornas 分享（15 个赞、6 条回复、687 次浏览）则将 trace-mcp 作为持久化代码上下文层。新意在于，研究框架与实践者工具正在收敛。
6.3 实时智能体店面正在到来，但差异化体验如今比货架本身更重要¶
两个公开表面格外突出。@ParkerOrtolani 浮现（7 个赞、880 次浏览）介绍了 xAI bot marketplace；公开网站显示，其中已有 69 个公开 Bots、43 位创建者和 9 个类别。@trythreews 展示了（75 个赞、19 条回复、1,985 次浏览）则展示了一个更丰富的公开表面，把具身交互、语音、身份、支付与 remix 结合在一起。真正值得注意的信号，不只是“市场已经出现”，而是团队已开始围绕智能体的完整交互与变现栈展开竞争。
7. 机会在哪里¶
[+++] 为长周期智能体工作构建持久上下文与验收所有权层¶
最清晰的产品空缺，是这样一层基础设施：决定智能体被允许做什么、它要带着哪些上下文继续运行，以及最终由谁验收结果。@AgentChud 说明了（503 个赞、72 条回复、66,563 次浏览、1,140 次收藏）把领域规则下沉到技能包层面；@daniel_mac8 分享（143 个赞、26 条回复、15,081 次浏览）展示了由 Astra 担任验收负责人的控制模型；@DanKornas 分享（15 个赞、6 条回复、687 次浏览）介绍了 trace-mcp 来保留代码结构；@rohanpaul_ai 强调（9 个赞、1 条回复、1,414 次浏览）则展示了跨多次编码运行保留证据。机会在于把这些理念打包成一层可审计、模型无关且适合生产环境的基础设施。
[++] 为自主行动构建独立验证与事故证据系统¶
关于可靠性的讨论，正在从“怎样把提示词写得更好”转向“怎样证明到底发生了什么”。@biscuitweb3 认为（89 个赞、77 条回复、4,196 次浏览）呼吁公开的事故式披露，@ghadfield 警告（34 个赞、2 条回复、3,187 次浏览）指出评估智能体过于轻信，@shivam74689 记录了（4 个赞、2 条回复、115 次浏览）则展示了带明确失败处理的有边界自我纠错。对于那些能够记录智能体动作、附加证据、将评估与执行分离，并生成可直接用于事故处理的记录的产品，这里存在明显机会。
[+] 构建避开人工瓶颈的智能体原生分发与变现路径¶
公开货架已经出现，但工作流仍很脆弱。@ParkerOrtolani 浮现（7 个赞、880 次浏览）展示了 xAI 市场，而 @trythreews 展示了（75 个赞、19 条回复、1,985 次浏览）展示了一个已接入身份与支付的平台。与此同时，@suraj_sharma14 汇编（39 个赞、8 条回复、1,613 次浏览）指出了实际阻塞点，其中包括仅限人类完成的注册门槛仍会破坏智能体原生工具使用。机会确实存在，但市场已经成形，最终更可能奖励执行质量，而非先发新奇感。
8. 要点¶
- 技能正在被重新定义为可安装、可测试的操作单元。最明确的证据来自 @AgentChud 交付（503 个赞、72 条回复、66,563 次浏览、1,140 次收藏）发布的尽调技能规范，以及 @earthtojake 发布中（166 个赞、6 条回复、7,940 次浏览）展示的真实 CAD 工作流技能库。
- 验证正在成为一门运营学科，而不只是基准测试学科。@biscuitweb3 询问（89 个赞、77 条回复、4,196 次浏览）呼吁事故式透明披露，而 @ghadfield 展示了（34 个赞、2 条回复、3,187 次浏览）指出评估智能体依然很容易被带偏。
- 现代智能体技术栈正在变厚：编排、代码图、浏览器运行时和共享记忆今天都以独立产品层的形式出现，分别体现在 @daniel_mac8 Astra Advisor（143 个赞、26 条回复、15,081 次浏览）、@DanKornas Omnigent（21 个赞、8 条回复、1,149 次浏览）和 trace-mcp（15 个赞、6 条回复、687 次浏览），以及 @alex_verem Obscura（5 个赞、3 条回复、1,215 次浏览）。
- 市场要的是结果证明，而不只是智能体供给。@mardehaym 认为（25 个赞、14 条回复、2,855 次浏览）呼吁采用与合并代码挂钩的采用指标，这与 @boringmarketer 这里（135 个赞、7 条回复、12,146 次浏览、384 次收藏）中仓库所有者对可观察完成状态的要求一致。
- 分发终于开始变得可见，但信任和注册仍是薄弱环节。公开的 xAI Bot Marketplace 和 three.ws 证明表面已经出现；@suraj_sharma14 捕捉到（39 个赞、8 条回复、1,613 次浏览）则解释了为何一旦上下文、沙箱或注册步骤缺失，工作流仍会中断。