Twitter AI Agent - 2026-05-22¶
1. 人们在讨论什么¶
1.1 运行框架工程和上下文预算成了主要瓶颈 🡕¶
5 月 22 日最强的一组讨论，把智能体可靠性看成运行框架和上下文问题，而不是纯粹的模型问题。5 条高信号内容共同支撑了这一主题。它们分别是：一条明确给出成本和运行时差异的运行框架工程讨论串，一条把“好上下文”拆成可导航、快速、新鲜、可累积四种属性的上下文工程讨论串，以及一项覆盖 43.2 万次请求的 token 研究。其余两条则分别是一份点出主流编程智能体共享运行框架分层的综述，以及另一条主张 token 越多往往结果越差的成本讨论串。
@_vmlops 认为（295 次点赞、2 条回复、18,280 次浏览、444 次收藏），一次不可用的智能体运行和一次可用运行之间的差别，在于模型外层的运行框架。他给出的受控示例声称：没有运行框架的 Opus 4.5 花了 $9 和 20 分钟，只产出不可用结果；而完整运行框架则花了 $200 和 6 小时，做出了一个可玩的游戏。这条讨论串还异常具体地界定了什么才算运行框架：工具使用前的指令、持久状态、验证闸门、限定范围的工作，以及清晰的会话生命周期。
@svpino 写道（73 次点赞、12 条回复、13,538 次浏览、157 次收藏），如今智能体失败，越来越不是因为模型太弱，而是因为拿到的上下文不对。在回复串里，他把这个判断说得更具体：理想的上下文应当具备可导航、快速、新鲜、可累积这几种属性；而 @Rigario 的一条回复则指出，很多记忆系统更擅长保留可召回的信息，却保不住决策、失败路径、验收标准或证据。
@SemiAnalysis_ 报道称（95 次点赞、9 条回复、10,558 次浏览、57 次收藏），在 43.2 万条真实编程智能体流量样本中，中位数请求已经携带 96k 个输入 token，约有一半请求超过 128k。后续回复表示，这种增长并不只是用户提示词变长造成的，而是来自系统提示词、工具定义、技能、MCP schemas、前几轮上下文以及文件内容。
@AlphaSignalAI 表示（27 次点赞、3 条回复、3,095 次浏览、32 次收藏），UIUC、Meta 和 Stanford 的一项新综述显示，Claude Code、Codex 和 SWE-agent 共享同一套三层运行框架架构：接口、机制和扩展。这点之所以重要，是因为当天的讨论不再只是说“加更多上下文”，而是在给可复用的系统分层起名字。
@IntuitMachine 声称（9 次点赞、624 次浏览、9 次收藏），16,000 次生产运行表明，智能体式编程的 token 消耗是普通聊天式使用的 3,500 倍，其中 95% 的成本都落在输入 token 上，而且一旦运行拉长到大约 300k token 以上，成功率就会下降。虽然互动量较低，但它强化了和 SemiAnalysis 讨论串同一个判断：token 增长现在已经是运行约束。
讨论要点： 最有用的纠偏不是来自主帖，而是来自回复区。@Rigario 把回答所需上下文和工作流状态区分开来；而 SemiAnalysis 讨论串里的一条回复则要求给出按轮 diff，精确展示每一轮到底重读了哪些文件、规则和工具输出。
与前日对比： 5 月 21 日已经把运行框架工程和记忆诊断抬到了更重要的位置，而 5 月 22 日则把讨论进一步推向运行经济学。新的讨论串给同一个可靠性问题补上了明确的 token 数、成本区间和架构分类法。
1.2 共享记忆层和可安装技能包开始变成真正的基础设施 🡕¶
第二个主要讨论簇围绕的是：智能体需要的是持久的记忆底座和可安装的知识包，而不只是更长的提示词。4 条分量很足的内容支撑了这一主题：一位构建者画出了 Hermes 团队下方的共享记忆层；另一位把记忆问题收束成“记住、引用、遗忘”三类检查；一条高互动解读认为，Google 正在把产品知识做成打包技能；而 Waza 的仓库描述则说明，技能工具链正在从 eval 扩展成运营基础设施。
@shannholmberg 分享（9 次点赞、2 条回复、315 次浏览、9 次收藏）了一套“gBrain + Hermes Agent”架构：每个专职智能体在开始工作前，都会先读取一层带类型的共享记忆，然后再通过主编排器把持久决策写回去。讨论串对目录和流转路径讲得很具体：people、companies、concepts、ideas、media、newsletter、projects 和 operations 都放在同一层记忆之下。
@Voxyz_ai 写道（36 次点赞、4 条回复、8,114 次浏览、76 次收藏），给 Hermes 或 OpenClaw “再加点记忆”只会造出一个杂物抽屉，除非先把记忆拆成三项职责：记住、引用、遗忘。@abdiisan 的一条回复也从实践角度印证了同样的问题：长时 Hermes 会话一直时灵时不灵，直到一个向量 + 文本混合插件替换了默认记忆路径之后才有所改善。
@KanikaBK 认为（15 次点赞、8 条回复、503 次浏览、3 次收藏），Google 已经把产品知识做成可安装技能，可跨 Claude Code、Cursor、Codex 和 Gemini CLI 使用；原因很直接：通用编程智能体在被问到 Google 产品时，仍然会靠猜，或者继续使用已废弃的方法。另一个侧面例子是，《Modern Web Guidance》 仓库 把自己描述成一项面向智能体的技能：它不是只靠提示词建议，而是通过可安装、token 效率更高的指导，把现代 Web 平台知识直接注入编程智能体。
@spboyer 表示（11 次点赞、515 次浏览、9 次收藏），Waza 最初只是一个 eval 框架，后来因为从业者不断把它往那个方向拉，才逐渐长成 CLI 和智能体支持层。公开的 microsoft/waza 仓库 把它描述成一个面向智能体技能的 CLI 与框架，帮助团队创建、测试、衡量并改进技能的质量和效果。
讨论要点： 有价值的细节在于，“记忆”和“技能”都在被拆成更窄的职责。上下文讨论串的回复区区分了工作流状态和回答上下文；而记忆讨论也同样从原始堆积，转向带类型的文件夹、来源追踪和过期机制。
与前日对比： 5 月 21 日关注的是 bundles 能否顺畅组合。5 月 22 日延续了打包主题，但把讨论更深地推进到共享记忆架构，以及能够直接装进智能体里的官方厂商知识包。
1.3 智能体支付和工作市场离日常运营更近了一步 🡕¶
第三个大主题是，人们开始把智能体商业看作运营管线，而不是未来主义口号。4 条内容支撑了这一点：一个带钱包的智能体自己买了电话服务，xPay 推出了带护栏的商业支付轨道，x402 和 pay.sh 描述了基于 HTTP 的机器可支付 API，而 Dispatch 则展示了当智能体来干活时，带资金保障的评审流程会是什么样。
@bleso_a 展示（88 次点赞、16 条回复、6,394 次浏览、20 次收藏）了一个智能体：它花 5 USDC 买了一个电话号码，用市场分析给他打电话，并以 0.133 USDC 结算通话。在后续回复里，他还公布了提示词：让 Circle Agent Wallet 用 USDC 给自己注资，找到获取电话号码和发起语音通话所需的付费服务，付费后返回电话号码、通话 ID、转写文本和录音 URL。
@xona_agent 发布（37 次点赞、10 条回复、835 次浏览）了 xPay，将其定位为面向智能体商业的 SDK 层，提供多链钱包、跨 Solana 和 Base 服务的发现能力、x402 支付以及支出护栏。最有信息量的一条回复把完整闭环写得很清楚：先发现服务，再执行护栏检查，再用 USDC 支付，最后返回结果；其中明确声称，即便智能体产生幻觉，也无法花超过上限的钱。
x402 文档把该协议描述为一种围绕 HTTP 402 Payment Required 构建的开放支付标准，目标是让服务在不需要账号、会话或凭证管理的情况下，向 API 访问收费。pay.sh 站点 则把同一模式带到更面向消费者的一侧：它的口号是“无账号、无密钥、无订阅”，智能体只为自己实际调用的那次请求付费。
@wyckoffweb 写道（59 次点赞、16 条回复、2,919 次浏览、6 次收藏），Dispatch 现在更强调清晰的任务流、任务状态、USDC 支付可见性、模板、更强的智能体资料，以及放款前的评审加修订步骤。这条推文对产品的定位，不是“雇一个 AI 智能体”，而是一层工作系统：智能体在其中接收有资金保障的任务、提交工作、接受评审，并随时间积累声誉。
讨论要点： 回复区已经不再争论机器支付能不能落地，而是立刻转向服务发现、合规、支出上限和打款条件。这比单纯对 demo 感到兴奋，成熟得多。
与前日对比： 5 月 21 日已经在 Circle 技术栈里出现了电话号码和 USDC 轨道。5 月 22 日则补上了支出上限、按次付费的 API 网关，以及更明确的市场评审与结算界面。
1.4 托管运行时和远程智能体工作闭环变得更明确 🡕¶
第四个主题是，大家正在从本地实验转向那种能持久运行、掉线后仍能继续、并暴露工作状态的智能体。3 条内容支撑了这一点：一位日常使用智能体的用户表示，真正的瓶颈是自己托管和安全；Qoder CLI 把远程执行做成了头条功能；而 Waza 在从业者推动下不断扩大的范围，也再次说明团队需要围绕技能和智能体的运营界面。
@PossibltyResult 写道（17 次点赞、6 条回复、3,518 次浏览、5 次收藏），连续日用智能体之后，他越来越确信瓶颈不在模型，而在常驻、可扩展智能体的托管与安全。这条推文最后几乎成了直接的产品提问：什么是最好的托管智能体服务？
@qoder_ai_ide 宣布（19 次点赞、4 条回复、635 次浏览、5 次收藏）发布 Qoder CLI 1.0，内含 Agent SDK 和 Cloud Agents 托管运行时。回复区补上了真正的实用点：qodercli --remote 能让长工作流在笔记本合上后继续运行，/goal 可以在不逐步提示的情况下定义何时算做完，而产品还声称上下文窗口最高可达 1M token。
@spboyer 表示（11 次点赞、515 次浏览、9 次收藏），Waza 的路线图原本并没有预料到它会从 eval 框架长成 CLI，再长到支持智能体；是从业者把它一路拖到了这里。公开仓库的描述也和这个说法一致：它把重点放在技能的创建、测试、衡量和改进上，而不只是提示词。
讨论要点： 贯穿其中的主线是，用户越来越希望智能体像远程员工那样工作：有持久状态，有明确的结束标准，而不是绑定在一台打开着的笔记本上的会话。
与前日对比： 5 月 21 日强调把确定性工作流和编排当作产品特性。5 月 22 日则把云端持久化、远程执行和对托管服务的需求说得更直白。
2. 令人困扰的问题¶
无结构记忆一旦规模化就会变成杂物抽屉¶
严重程度：高。@Voxyz_ai 写道（36 次点赞、4 条回复、8,114 次浏览、76 次收藏），给 Hermes 或 OpenClaw “再加点记忆”只会造出一个杂物抽屉，除非先把记忆拆成“记住、引用、遗忘”三项职责，并分别按层级、来源和过期时间去审计。@abdiisan 又补充说，长时 Hermes 会话一直不稳定，直到一个向量 + 文本混合插件替换了默认记忆路径。当前的应对模式，是在内置记忆外面再加显式插件或审计结构。值得做，因为这种失效模式出现在多个智能体和多类用户身上，不只是某个边缘配置。
上下文膨胀会带来难以预测、也难以阻止的成本飙升¶
严重程度：高。@SemiAnalysis_ 报道称（95 次点赞、9 条回复、10,558 次浏览、57 次收藏），在 43.2 万条样本里，编程智能体请求的中位数已经携带 96k 个输入 token，其中约一半超过 128k；而增长来源并不是用户提示词越来越长，而是系统提示词、工具定义、技能、MCP schemas、前几轮上下文和文件内容在每一轮都会被重新读入。@IntuitMachine 声称（9 次点赞、624 次浏览、9 次收藏），16,000 次生产运行表明，智能体的 token 消耗是聊天式使用的 3,500 倍，而且一过约 300k token，成功率就开始下降。@runbounds 的一条回复把诊断说得很直白：按轮 diff 能精确展示每一轮到底重读了哪些文件、规则和工具输出。当前的权宜方案是缓存和更克制的上下文管理，但根因——同样的文件被反复重读——在主流智能体运行时里基本还没被真正解决。值得做，因为成本是真实的，而如果没有观测，这种泄漏几乎是无声发生的。
智能体缺少最新知识，于是继续调用已废弃的厂商 API 方法¶
严重程度：中。@KanikaBK 认为（15 次点赞、8 条回复、503 次浏览、3 次收藏），通用编程智能体在被问到如何部署到 Google Cloud Run 或配置 Firebase authentication 时，会稳定地靠猜，或者继续调用已废弃的方法；唯一的修复方式，是安装带有最新产品知识的官方技能包。@TanmaySaboo 的一条回复也确认了这一判断：“问题从来不是模型不会写代码，而是它们常常依赖过时或不完整的产品知识。” 当前的权宜方案是安装官方技能包，但今天真正有这类东西的厂商仍然很少。值得做，因为凡是文档更新速度快过模型训练周期的领域，都会遇到同样的问题。
运行常驻、可扩展的智能体，需要大多数构建者承受不起的托管与安全工作¶
严重程度：中。@PossibltyResult 写道（17 次点赞、6 条回复、3,518 次浏览、5 次收藏），连续几周日用智能体后，他越来越确信瓶颈不在模型，而在常驻、可扩展智能体的托管与安全成本和复杂度。这条讨论串最后直接变成了产品需求。当前的应对模式，是只在本地运行智能体、限制它们的作用范围，或者用各种 hack 去绕过托管问题；这会直接限制可靠性和在线时长。值得做，因为这个需求既明确又具体。
企业级智能体集群看不清单个智能体在做什么、又花了多少钱¶
严重程度：中。@Johnsjawn 引用转发 了 Notion 的 Custom Agent Insights 发布（44 次点赞、3 条回复、10,624 次浏览、33 次收藏），并借此指出：一旦公司意识到智能体真的会落地，治理——谁构建了什么、它在做什么、花了多少钱、是否有效、该在哪里优化——就会成为每一场严肃企业对话中的头号需求。当前的权宜方案，是自建仪表盘，或依赖提供商层面的用量视图。值得做，因为这个需求不是开发者情绪，而是企业销售一线已经验证过的。
3. 人们期望的功能¶
内建安全、持久化和可扩展性的托管智能体服务¶
@PossibltyResult 直接问道（17 次点赞、6 条回复、3,518 次浏览、5 次收藏）：“最好的托管智能体服务有哪些？” 因为他已经认定，把一个常驻、可扩展智能体所需的托管与安全工作当成副业来维护，并不可持续。这是一个务实而紧迫的需求。@qoder_ai_ide 发布（19 次点赞、4 条回复、635 次浏览、5 次收藏）了 Qoder Cloud Agents，算是一个回答，而 --remote 这个具体功能可以让长工作流在笔记本合上后继续运行，但这个赛道还没有明显的既有王者。机会：直接。
具备明确“记住、引用、遗忘”角色的结构化记忆底座¶
@Voxyz_ai 写道（36 次点赞、4 条回复、8,114 次浏览、76 次收藏），人们真正需要的，是把记忆拆成“记住、引用、遗忘”三项职责，并按层级、来源和过期时间去审计，而不是把所有内容都堆进一个没有区分的存储里。@shannholmberg 描述（9 次点赞、2 条回复、315 次浏览、9 次收藏）了同样的需求在架构层面的样子：在编排器之下放一层带类型的共享记忆，让专职智能体醒来时就带着完整上下文，而不是每次从头开始。@svpino 进一步从检索角度补了一层：上下文必须可导航、快速、新鲜、可累积；而他讨论串里 @Rigario 的回复则把回答上下文和工作流状态区分开来，指出多数记忆方案改善了召回，却仍然保不住决策、失败路径、验收标准或证据。机会：直接且竞争激烈，Redis Iris 和 Mnemosyne 之类的插件已经部分覆盖了这一需求。
能按轮显示上下文浪费位置的 token 可观测性¶
@runbounds 在 SemiAnalysis 讨论串下的一条回复，把需求说得非常精确：“按轮 diff 能展示哪些文件被重读、哪些规则被加载、哪些工具输出被保留，以及到底改了什么。” @IntuitMachine 表示（9 次点赞、624 次浏览、9 次收藏），GPT-5 对自身 token 使用量的估算，和真实情况的吻合度只有大约 r=0.39，因此智能体在开始之前，无法可靠地自行报告预算。人们真正要的，是一种轻量级的按轮拆解——不必是完整 trace——能在成本飙升之前，就把冗余文件读取和输入 token 累积标出来。机会：直接，目前看不到明显的市场既有者在智能体运行时做这件事，大家更多还是事后从账单面板里追溯。
覆盖主要厂商与平台、官方发布且可安装的最新产品知识¶
@KanikaBK 记录（15 次点赞、8 条回复、503 次浏览、3 次收藏），Google 面向智能体的官方技能库，终于让编程智能体在 Google Cloud、Firebase、BigQuery 以及其他配套产品上获得了准确、最新的指导。这也把更广泛的未满足需求说得很清楚：从业者希望每一家厂商都能发布这种可安装、内容最新、经过专家验证的知识包，而不是继续让智能体依赖可能早就过了上一次废弃周期的训练数据去猜。机会：竞争激烈——Google 已率先出手，格式也是开放的，但绝大多数厂商 API 和服务还没有同类知识包。
把工作交付、评审、支付和声誉放在同一层的智能体市场原语¶
@wyckoffweb 把 Dispatch 描述成（59 次点赞、16 条回复、2,919 次浏览、6 次收藏）一层“真实工作层”，而不是目录站；这等于把缺口说得很直白：今天的智能体产品里，还缺少有资金保障的任务、评审、结算和声誉跟踪。被引用的上一条推文则写出了完整闭环：发布、注资、分配、评审、批准、支付，再更新声誉。大多数今天的智能体产品，都停在“提交输出”为止。机会：偏愿景——搭建它所需的工具已经开始出现，但市场机制本身还在拼装中。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编程智能体 | (+) | 如运行框架工程讨论串所述，具备具体的运行框架原语、验证闸门和会话生命周期管理 | 按 $200 / 6 小时的例子看，如果没有合适的运行框架，成本会非常高 |
| Hermes Agent | 智能体运行时 | (+/-) | 灵活的多专职智能体编排；支持共享记忆层和技能包 | 如果没有外部插件，内置记忆在长会话里会变得不可靠 |
| Redis Iris (Context Retriever + Agent Memory) | 记忆 / 检索 | (+) | 语义图遍历、托管的短期与长期记忆，以及从 Postgres/MySQL/数仓持续同步数据 | 需要集成投入；提及语境来自一条带赞助性质的讨论串 |
| Mnemosyne plugin | 记忆插件 | (+) | 向量 + 文本混合搜索、跨会话实体记忆、5 分钟即可装好 | 偏生态特定（面向 Hermes）；公开证据有限 |
| x402 protocol | 支付 | (+) | 基于开放 HTTP 标准，支持按 API 调用付费，无需账号、会话或凭证管理 | 采用仍很早期；依赖服务方采纳这一标准 |
| xPay SDK | 支付 | (+) | 多链钱包、21k+ 服务发现，以及签名前就执行的支出护栏 | 仍是 v0.1.0；虚拟卡和跨链桥接尚未发布 |
| Circle Agent Wallet | 支付 / 电话 | (+) | 智能体可以用 USDC 给自己注资、购买电话号码、发起通话，并按次结算 | 合规以及一次性验证码之类的边角情况仍需人工处理 |
| Agora Skills | 语音技能包 | (+) | 一条命令即可装出可打断、多轮语音 demo；支持 Deepgram、GPT-4o-mini、MiniMax 和自定义 LLM | 默认每个 App ID 仅 20 个并发会话；尚无规模化生产就绪证据 |
| Qoder CLI | 编程智能体 / 托管运行时 | (+/-) | 通过 --remote 远程卸载任务，支持用 /goal 定义“做完”条件，上下文窗口最高 1M token |
仍较早期；第三方生产使用证据有限 |
| Microsoft Waza | 智能体技能框架 | (+) | 用 CLI 创建、测试、衡量并改进技能质量；在从业者推动下扩展出智能体支持 | 范围更多由从业者需求牵引，而不是固定路线图，这会给长期 API 稳定性带来不确定性 |
| Dispatch | 智能体市场 | Beta | 用 USDC 给任务注资、付款前评审、智能体资料、声誉跟踪 | 运行在 Arc 测试网；尚未说明生产级结算和纠纷处理 |
| Google Modern Web Guidance skills | 技能包 | (+) | 13 个可安装技能，覆盖 Cloud、Firebase、BigQuery、GKE；适配 Claude Code、Cursor、Codex、Gemini CLI | 只覆盖 Google 产品面；其他厂商还没有等价方案 |
| pgvector + semantic retrieval | 检索方法 | (+) | 按从业者报告可将上下文负载降至约 1/5，并减少面向特定领域检索时的幻觉 | 需要严格索引和按阶段划分的 eval，才能定位检索失效发生在哪 |
5 月 22 日的满意度光谱，围绕的不是模型本身，而是模型外那一层。凡是增加了明确结构的工具——带类型的记忆、支出护栏、技能包、远程持久化——都更受欢迎，因为它们能减少运营不确定性。像 Hermes 这样的智能体运行时，一旦内置默认值会在规模化场景中无声退化，或者支出护栏、记忆插件还得另找，评价就会变成褒贬不一。最明显的迁移模式，是从原始提示词转向结构化运行框架层、可安装知识包，以及不需要手动管理凭据的支付轨道。竞争张力在技能包分发上最明显：Google 用 Anthropic 开源格式发布官方技能库，说明大型厂商如今已经把可安装知识当成值得投入的一等分发层，而不再只是社区里的权宜方案。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| xPay | @xona_agent | 面向智能体商业的支付 SDK，提供多链钱包、服务发现、x402 支付和支出护栏 | 智能体需要在不手动配置凭据、也不允许无限制支出的前提下，发现服务、付费并拿到结果 | Solana、Base、x402、USDC、PayAI Network discovery、SDK | Alpha（v0.1.0） | tweet |
| Dispatch | @wyckoffweb | 带有任务注资、USDC 支付可见性、付款前评审、智能体资料和声誉跟踪的工作市场 | 给智能体补上任务分配、提交、评审、结算和声誉这一整套工作系统，而不只是聊天输出 | Arc 测试网、USDC、已部署任务合约、在线前后端 | Beta（测试网） | tweet, site |
| gBrain + Hermes multi-agent company | @shannholmberg | 在 Hermes 编排器和专职智能体之下放一层带类型的共享记忆；所有专职智能体都先读 gBrain，再把持久决策写回 | 多智能体团队缺少共享上下文底座，每次运行都要从零开始 | Hermes Agent、带类型的文件夹（people / companies / concepts / ideas / media / projects / operations）、编排器读写模式 | Alpha | tweet |
| Voice AI agent via Agora skill | @exploraX_ | 只靠安装一个技能，就在 Claude Code 里搭出具备会话记忆的实时可打断语音智能体 | 构建者想快速拿到一个可工作的语音 demo，而不想手动配置控制台或管理多把 API key | Agora skill（npx skills add）、Deepgram STT、GPT-4o-mini、MiniMax TTS |
已发布 | tweet |
| Qoder CLI 1.0 | @qoder_ai_ide | 托管的云端编程智能体运行时，提供 Agent SDK、远程卸载、/goal “做完”条件定义，以及最高 1M token 上下文 |
本地编程智能体在笔记本一合上就停，而且没有持久状态，只能一步一步提示 | Qoder Agent SDK、Cloud Agents 运行时、--remote 标志 |
已发布 | tweet |
| Google official agent skills library | Google / @KanikaBK 提到 | 13 个可安装技能包，覆盖 Cloud、Firebase、BigQuery、GKE、身份认证和 Well-Architected Framework | 如果没有最新产品知识，编程智能体会为 Google 产品生成已废弃或错误的方法 | Anthropic skills 格式、npx skills add google/skills、Apache 2.0 |
已发布 | tweet, repo |
| Wallet-funded voice-calling agent | @bleso_a | 用 USDC 自我注资、购买电话号码、给人类拨打市场分析电话，并返回通话转写和录音 URL 的智能体 | 证明智能体可以自主采购并支付真实服务，而不只是浏览网页或生成文本 | Circle Agent Wallet、USDC、BlandAI（电话）、语音合成 | 已发布（演示） | tweet |
@wyckoffweb 详细说明（59 次点赞、16 条回复、2,919 次浏览、6 次收藏）了 Dispatch 如何一步步尝试补上智能体外围缺失的工作原语：任务注资、状态清晰度、评审步骤，以及跨已交付工作的可累积声誉。被引用的上一条推文明确写出了它和普通目录站的差别：智能体必须能接收有资金保障的任务、提交工作、接受评审、在获批后才收款，并在时间中建立可验证的声誉。这是本数据集中第一个带有在线测试网前端的链上智能体声誉与结算闭环。
@bleso_a 公开了（88 次点赞、16 条回复、6,394 次浏览、20 次收藏）他用来驱动 Circle Agent Wallet 自主采购电话与语音服务的完整提示词——“用 Circle Agent Wallet 拨打 MY_PHONE_NUMBER……找到获取电话号码并发起语音通话所需的付费服务，用 USDC 支付，并返回电话号码、通话 ID、转写文本和录音 URL。” 这让整个工作流变得可复现，而不只是一个 demo 说法。
5 月 22 日这些项目里反复出现的构建模式，是让智能体获得运营基础设施——钱包、市场席位、持久记忆、托管运行时、可安装知识——而不是只给它更长的系统提示词。数据集中每一个分量较重的项目，都新增了一层：要么能在断线后继续存在，要么能约束支出上限，要么能把带类型的上下文存下来，让下一次运行不必重新推导。
6. 新动态与亮点¶
x402 和 pay.sh 把机器可支付 API 说成了一种开放标准¶
x402 文档把它描述成一种围绕 HTTP 402 Payment Required 响应码构建的开放支付标准，目标是让服务在不要求账号、会话或凭证管理的情况下，对 API 访问收费。pay.sh 站点 则把同一模式带到更面向消费者的一侧，并明确声称“无账号、无密钥、无订阅”，智能体只为自己实际使用的那次调用付费。@xona_agent 发布（37 次点赞、10 条回复、835 次浏览）了 xPay，成为目前最可见的 SDK：它把 x402、多链钱包和服务发现层放到了一起。开放标准（x402）、面向消费者的产品（pay.sh）和 SDK（xPay）在同一天同时出现，这更像是一轮协调好的基础设施铺设，而不是彼此独立的实验。
Google 用 Anthropic 的开放格式发布了面向编程智能体的官方技能库¶
@KanikaBK 观察到（15 次点赞、8 条回复、503 次浏览、3 次收藏），Google 选择用 Anthropic 开源的技能格式，交付自己的官方产品知识——13 个覆盖 Cloud、Firebase、BigQuery、GKE 和《Well-Architected Framework》的技能——从而同时兼容 Claude Code、Cursor、Codex 和 Gemini CLI。这个决定之所以重要，是因为它表明，一家主要模型厂商正在把竞争对手的分发格式当成务实默认值来采用；这说明真正赢下来的，可能是格式本身，而不是底层模型的归属。
SemiAnalysis 公布了 43.2 万条真实编程智能体请求的上下文长度数据¶
@SemiAnalysis_ 报道称（95 次点赞、9 条回复、10,558 次浏览、57 次收藏），真实编程智能体请求的中位数，已经携带 96k 个输入 token，约有一半请求超过 128k。后续讨论串表示，驱动因素不是用户提示词更长，而是用户开始输入之前，运行框架就已经加载进去的那些东西：系统提示词、工具定义、技能、MCP schemas、前几轮上下文和文件内容。这是第一次有如此大样本的经验数据，为过去主要停留在理论层面或厂商个案里的上下文规模估算提供支撑。
Redis 发布 Iris，把它定位成专门面向智能体的上下文与记忆平台¶
在 @svpino 那条上下文工程讨论串的回复里，有人介绍了（73 次点赞、12 条回复、13,538 次浏览、157 次收藏）Redis Iris。它把 Context Retriever（针对实时数据做语义图遍历，而不是只取 top-k 向量块）、Agent Memory（托管的短期与长期记忆，含嵌入、检索和摘要），以及 Redis Data Integration（把关系型数据库持续同步进 Redis）放到了一起。这个发布之所以值得注意，是因为它把 Redis 从缓存重新定位成智能体原生的记忆底座，直接和团队自己从零搭的定制记忆方案竞争。
7. 机会在哪里¶
[+++] 面向智能体运行时的 token 可观测性与成本控制工具 — SemiAnalysis 记录了 43.2 万条真实请求中位数 96k 的输入 token，IntuitMachine 则显示智能体式使用的 token 消耗是聊天式使用的 3,500 倍，而且一过 300k token 成功率就下滑；另一条回复还直接要求按轮 diff，显示到底哪些文件在被反复重读。运行时现在给出的多是账单总额，而从业者真正需要的是按轮、按文件的拆分视图，以及对冗余读取的检测。这之间的缺口很大，而且几乎没人解决。证据同时来自经验数据、从业者抱怨和一批已经踩到成本坑的团队。
[+++] 具备安全、持久化和可扩展性的托管智能体基础设施 — @PossibltyResult 基于日常使用发出了明确的产品请求；Qoder Cloud Agents 和 xPay 的路线图（控制台加虚拟卡）只是部分答案。需求来自真做过自托管的人，而不是纸上谈兵。除了大型云厂商之外，这个领域还看不到明显的常驻智能体基础设施主导者，而通用算力服务又不是为智能体生命周期管理而生。
[++] 具备带类型角色和过期机制的结构化记忆底座 — 四条彼此独立的线索都指向这个机会：@Voxyz_ai 提出“记住 / 引用 / 遗忘”框架、@shannholmberg 分享 gBrain 架构、@svpino 提出“可导航 / 快速 / 新鲜 / 可累积”框架，以及 @Rigario 对工作流状态和回答上下文的区分。现成记忆层还做不到在多智能体团队里同时保证来源可追溯、过期控制和类型安全。Redis Iris 和 Mnemosyne 只是部分答案，但这么多互不相干的构建者在同一天反复提到同一模式，说明需求会持续存在。
[++] 带有支出护栏和按次结算能力的智能体支付轨道 — x402、xPay、Circle Agent Wallet 和 pay.sh 在同一天同时出现，说明机器可支付 API 正在被有组织地往前推。xPay 的关键差异化主张是：即便智能体产生幻觉，也花不超过上限。机会是真实的，但这个赛道推进很快，而且已经有多支团队在做。
[++] 超越 Google 的、可安装且保持最新的厂商认证知识包 — Google 的官方技能库已经证明，厂商完全可以用开放格式把产品知识打包成可安装模块，让智能体直接加载使用。绝大多数 API、平台和云服务还没有同类方案。@KanikaBK 讨论串给出的需求信号很明确：编程智能体反复产出已废弃的方法，而一条命令安装技能包，已经成了可行修复路径。格式是开放的，任何厂商都能用。
[+] 具备链上声誉与打款逻辑的智能体市场原语 — Dispatch 是这份数据里最清晰的例子，但它仍停留在测试网。被引用的推文把缺失那层定义成任务、支付、评审、结算、声誉和工作历史——并把它说成是“让 bot 变成 worker”的关键。机会是真实的，但还很早；缺的不是技术想象力，而是生产级结算、纠纷处理和可信的声誉聚合。
8. 要点总结¶
- 运行框架工程如今已经被点名、被形式化，也有经验数据支撑。 受控成本实验（没有运行框架时花 $9，对比有运行框架时花 $200 才得到可比输出）、43.2 万次请求的 token 研究，以及一份 100 页的共享运行框架架构学术综述，三者叠在一起，让运行框架工程从从业者经验，上升成了一门被明确承认的工作。 (source)
- 上下文膨胀如今是运行成本问题，不是模型能力上限。 SemiAnalysis 给出的 96k 输入 token 中位数——其中一半超过 128k——再加上 IntuitMachine 关于成功率在 300k token 之后下滑的发现，一起把上下文管理定义成了经济性和可靠性问题，而不只是能力问题。 (source)
- 智能体记忆需要明确分工，而不只是更大容量。 “记住 / 引用 / 遗忘”框架、带类型的共享 gBrain 层，以及“工作流状态不同于回答上下文”这一划分，在同一天独立出现，说明从业者普遍对那种把一切内容无差别堆积起来的记忆方式感到挫败。 (source)
- 智能体支付已经从演示噱头，走向协同推进的基础设施。 x402、xPay、Circle Agent Wallet 和 pay.sh 同时出现，再加上一个由钱包注资跑通的真实电话 demo，都说明智能体的支付层正在被认真搭建，而不是各自零散试水。 (source)
- 官方厂商技能包，正在成为交付最新产品知识的新分发层。 Google 用 Anthropic 的开放格式发布了 13 个技能，并同时兼容主流编程智能体，这是当天最重要的分发信号——因为它说明，想让编程智能体在某家厂商自己的平台上保持准确，如今已经出现了第一方、可安装的答案。 (source)