Twitter AI 智能体 - 2026-05-18¶
1. 人们在讨论什么¶
1.1 运行框架工程成了可靠智能体的共同语言 🡕¶
运行框架工程仍是当天最清晰的重心，但证据已经从零散技巧，转向公开课程、设计指南和可重复的运行闭环。最有分量的帖子，不再把智能体当成“更聪明的提示词”，而是把它们视为需要状态、验证、可观测性、恢复机制、权限和明确归属的系统。相比 5 月 17 日那种已经围绕课程和生产闭环展开的讨论，5 月 18 日把话题进一步扩展到了更明确的设计工件和企业落地角色。
@_vmlops 分享了 《Learn Harness Engineering》课程（2,034 次点赞、11 条回复、119,999 次浏览、3,479 次收藏）。页面介绍称，这门课会讲解面向 Codex 和 Claude Code 风格智能体的环境设计、状态管理、验证、可观测性和控制系统；截图之所以重要，是因为课程列表围绕的是具体失效模式来组织的：连续性丢失、过早宣告胜利、可观测性缺失，以及端到端测试改变结果。
@shannholmberg 描述了（211 次点赞、20 条回复、18,147 次浏览、327 次收藏）一个 Hermes 从原型到生产的工作流：先在主编排器里把某个专家跑 4-10 次，纠正漂移，让技能自然浮现，必要时再用 Claude Code 或 Cursor 进一步收紧，最后部署成一个专用的 Docker 化智能体。配图补上了操作细节：一次跑干净的流程会被迁移进专家容器，配上作用域受限的凭据、作用域受限的记忆，以及生产就绪的配置。
@_vmlops 还 发布了（139 次点赞、5,141 次浏览、124 次收藏）《Harness Engineering: A Design Guide to Claude Code》的封面图。它的视觉框架——控制平面、循环、恢复、权限、中断、验证，以及“先有系统，再谈模型”——与课程公开强调的观点一致：运行框架之所以能让智能体更可靠，是因为它约束了行为，并让运行时变得可调试。
@dani_avila7 认为（52 次点赞、4 条回复、21,387 次浏览、58 次收藏），企业里的 Claude Code 落地之所以失败，是因为“模型在变强，配置却没跟上，而且没人真正负责”。配图点出了一个正在浮现的 Agent Manager 角色：负责 Claude Code 的配置、权限策略、插件市场、CLAUDE.md 约定，以及持续更新设置。
讨论要点： 最有价值的反驳集中在漂移和治理上。在 Hermes 那条工作流帖子下面，@cdiamond 提醒说，一旦生产输入不再匹配测试简报，第三轮迭代里修正过的漂移很可能会重新冒出来。而在 @code_rams 的七组件运行框架帖子（5 次点赞、4 条回复、415 次浏览、14 次收藏）下，又有人补充了“规格门控”这一点：规划器应该提出规格变更，而不是悄悄改写验收标准。
与前日对比： 5 月 17 日把运行框架工程描述为课程体系加部署实践。到了 5 月 18 日，它更像制度化建设：指南、落地阶段、Agent Manager 归属，以及规格门控。
1.2 智能体市场和运营层从概念走向产品化宣称 🡕¶
第二个讨论簇把下一个智能体瓶颈，看成选择、协调和结算，而不是模型能力本身。LobeHub 在主打 Chief Agent Operator，AgenC 描述的是“运行时 + 市场”，x402/x402B 一类帖子把托管机制视为必要的信任基础设施，TermiX 则发布了链上市场指标。共同的论点是：自治智能体需要一套基础轨道，来回答由谁干活、如何付款，以及结果如何审查。
@lobehub 推出了（224 次点赞、60 条回复、60 条引用、422,145 次浏览、104 次收藏）一个 Chief Agent Operator，它会“从 27.3 万技能市场里雇佣智能体”，让它们在云端 24/7 运行，并通过即时通信应用回报结果。来自 @CatCatBros 的一条回复说 Discord 接入“非常简单”，而 LobeHub 还追问下一个该支持哪个 IM 渠道，这让“通过现有工作聊天工具分发”也成了产品叙事的一部分。
@tetsuoai 表示（86 次点赞、9 条回复、3,976 次浏览、15 次收藏），AgenC 是一整套智能体运营层：本地守护进程、网关、CLI、TUI、仪表盘、审批、记忆、可观测性、工作流执行、由 Solana 支撑的协作、市场轨道，以及 ZK/prover 系统。截图则把细节落到了终端界面上：编排器身份、钱包、质押、声誉、slash 机制、权限模式，以及一个 /claim 市场流程。
@Onyx_goose 把（57 次点赞、48 次转发、5 条回复、129 次浏览）x402 形容为“智能体的 HTTPS”，把 x402B escrow 说成智能体商业里类似 SSL 证书的信任层。配图把机制讲得更明白：只有当自治交易双方满足预先约定的条款并经核验后，条件式托管才会放款。
@termix_ai 报告（43 次点赞、4 条回复、8,130 次浏览），其运行在 BNB Chain Testnet 上的 AACP 已累计结算 2,310,330 美元的智能体商业成交额，拥有 8,194 个智能体、9,290 个 A2A 任务、日均 374 个新增任务，以及 741,606 美元锁仓。@clawdbotatg 声称（77 次点赞、99 条回复、3,384 次浏览）已部署 141 份合约、链上资金超过 300K 美元、销毁 12.6 亿枚 $CLAWD，并有 6 次治理投票由质押者训练的小型智能体决定；一条回复质疑 11.3B 的质押量是否代表真实使用，作者则回应说：“工作发生在委托上，不在锁仓本身。”
讨论要点： 信号最强的回复，关注的都是信任和工作验证，而不是炒作。在 AgenC 的帖子下，@TheOnChainDev 追问原生的智能体到智能体支付是已经支持，还是还在路线图上；而 x402 的回复则把托管机制的价值说得很直接：自治交易对手彼此可能根本不认识。
与前日对比： 5 月 17 日的商业主题更多在讲身份、治理、支付、验证和用户控制这些缺失的基础轨道。到 5 月 18 日，大家已经在更具体地尝试把这些轨道做出来：CAO 市场、Solana 运行时结算、x402B 托管，以及 AACP 的使用数据。
1.3 开发者正在把技能、记忆和多智能体协作打包成产品 🡕¶
这组开发者讨论的重点不是新基础模型，而是怎么把智能体工作做得可复用、可追踪。共同方向很明确：把能力封装成技能、持久化状态、协调多个智能体，并让工作过程可审计。
@mercury__agent 表示（176 次点赞、9 条回复、5 条引用、1,040 次浏览），Mercury 正在从“和代码聊天”迈向规划、受控执行和原生基于 Git 的工作流。链接到的 GitHub 仓库 把它描述成一个 TypeScript 智能体：带权限加固工具、token 预算、CLI/Telegram 入口、由 SQLite 支撑的“第二大脑”记忆，以及 24/7 守护进程模式；有条回复问，为什么不直接用 /plan，Mercury 的回答是：命令本身很简单，“关键在于围绕它搭起来的整套系统。”
@GithubProjects 分享了《Gas Town》（37 次点赞、2 条回复、3,346 次浏览、31 次收藏），这是一个多智能体工作区管理器。截图写得很具体：它可以协调 Claude Code、GitHub Copilot、Codex、Gemini 等智能体，把工作持久化到 Git 支撑的钩子和 Beads 台账里，加入邮箱和交接机制，并把“4-10 个智能体就会失控”变成“可以舒服地扩展到 20-30 个智能体”。
@tom_doerr 分享了 《OpenSkills》，这是一个 TypeScript 通用技能加载器，在 GitHub 上已有 10,200 星，能把 Claude Code 风格的 SKILL.md 文件带到 Claude Code、Cursor、Windsurf、Aider、Codex，以及其他会读取 AGENTS.md 的智能体中（22 次点赞、6 条回复、1,751 次浏览、21 次收藏）。回复区点出了尚未解决的取舍：有人说它要么是“多工具噩梦”，要么是“游戏规则改变者”；也有人说，上下文窗口到第四轮就可能把技能吃掉，逼得智能体重新发明整套循环。
@tom_doerr 还 发布了 《Mimeo》（12 次点赞、4 条回复、1,549 次浏览、18 次收藏），其 GitHub 元数据把它描述成一个 Python 工具，可以把专家思路“转写”成 SKILL.md 或 AGENTS.md。
@CopilotKit 推出了（21 次点赞、1 条回复、1,047 次浏览、16 次收藏）《CopilotKit Threads》，用于在任意智能体框架上基于 AG-UI 构建可持久化、可恢复、类似 ChatGPT 的对话。
@DarkWebInformer 分享了（9 次点赞、2 条回复、2,101 次浏览、17 次收藏）《Pentest Agents》，这是一个面向 Claude Code、Codex、Gemini 等多种编程智能体的 Python 漏洞赏金框架，带有自治式漏洞搜寻循环和利用链构建器。
讨论要点： @pvncher 认为（23 次点赞、4 条回复、3,017 次浏览、12 次收藏），编排最有效的方式仍然是以串行为主的任务拆解，而不是智能体蜂群。在回复里，他说任意的智能体间消息传递会带来无关细节、把工作带偏；并行适合只读任务，但写入路径需要加锁和验证。
与前日对比： 5 月 17 日强调的是自进化技能和官方技能包。5 月 18 日则更突出可移植性和工作区产品：跨智能体技能、持久对话、Git 原生工作痕迹，以及多智能体协作。
1.4 质疑主要集中在安全、OOD 失败和模型价格取舍上 🡒¶
这一天并不是一边倒地看多。最强的质疑都来自具体失败案例：编程智能体做不出给孩子用的火箭模拟器，只靠提示词的安全防护看起来很薄弱，MIT 展示了针对当前模型的提示词注入，而 Cursor Composer 2.5 也引发了“速度还是智能”之争。
@omarsar0 表示（60 次点赞、28 条回复、14,785 次浏览、16 次收藏），当他让编程智能体去做火箭模拟器这类以科学为主题的模拟器时，它们一次次让他 10 岁的孩子失望。在回复里，他说自己试过提示词辅助和上下文工程技巧，但这些智能体连一个勉强能用的 2D 模拟器都做不出来。他的结论很克制，也有证据支撑：编程智能体更擅长扩展训练数据里大量出现的模式，不擅长处理分布外的创造性模拟器任务。
@RoundtableSpace 发布了（53 次点赞、9 条回复、38,508 次浏览、36 次收藏）一条很长的“安全优先智能体”提示词，内容覆盖提示词注入、越狱、数据外泄、最小权限和不安全的工具使用。回复区立刻分化：有人说几乎没人真正做智能体安全；@bygregorr 追问这会不会只是“把安全感寄托在系统提示词上”；@sanarsh11 则把它形容成“不过是在纸盾牌上套了层提示词盔甲”。
@anishathalye 说（27 次点赞、3 条回复、1,692 次浏览、20 次收藏），MIT CSAIL 的一场客座讲座成功演示了针对 Anthropic Opus 4.6 模型的提示词注入，并得出结论：智能体安全仍未解决。他在回复里补充说，完整讲座还涵盖 ReAct、CodeAct、智能体安全、Simon Willison 的双 LLM 模式，以及 CaMeL 的能力系统。
@minchoi 把（33 次点赞、14 条回复、5,962 次浏览、8 次收藏）Cursor Composer 2.5 描述成更便宜、也更适合长时运行智能体工作的模型。真正有用的是一条测试者回复：他说 Composer 2.5 体感“快得惊人”，性价比也不错，但智能水平仍追不上 Opus 或 GPT-5.5，而且还会犯一些“很蠢的错误”。
讨论要点： 关于安全的回复异常直接。凡是提出“提示词防御”的帖子，几乎都会立刻遭到质疑：单靠提示词，真能阻止数据外泄或多语言泄漏吗？整体模式并不是反对智能体，而是反对没有验证支撑的安全宣称。
与前日对比： 5 月 17 日已经有人在警告恶意智能体供应链。5 月 18 日则把这种质疑扩展到了提示词注入演示、对纯提示词防御的批评、OOD 编程失败，以及模型层面的取舍。
2. 令人困扰的问题¶
可靠智能体需要明确归属，不只是更好的模型¶
严重程度：高。@dani_avila7 说（52 次点赞、4 条回复、21,387 次浏览、58 次收藏），只要没人负责配置、权限、技能和约定，企业里的 Claude Code 落地就会撞上同一堵墙。@code_rams 列出了（5 次点赞、4 条回复、415 次浏览、14 次收藏）约束、状态、验证、可观测性、模块化结构、洁净状态协议和行为约束等必需的运行框架组件。目前浮现出的权宜方案，是设一个专门的 Agent Manager/DRI，再加上规格门控，但这个需求在运营层面仍未真正解决。
智能体安全既紧迫，又明显没建好¶
严重程度：高。@anishathalye 展示了（27 次点赞、3 条回复、1,692 次浏览、20 次收藏）MIT CSAIL 讲座里针对 Opus 4.6 的提示词注入；@RoundtableSpace 发布了（53 次点赞、9 条回复、38,508 次浏览、36 次收藏）一条安全提示词，回复区却直言远远不够。@DarkWebInformer 分享了（9 次点赞、2 条回复、2,101 次浏览、17 次收藏）Pentest Agents，但有条回复警告说，静态的智能体脚本可能会幻觉出“发现”，却拿不出真正的利用路径证明。眼下的应对模式是分层叠加：提示词、最小权限、能力系统、利用证明，以及人工复核。
编程智能体在分布外的创造性任务上仍让人失望¶
严重程度：中。@omarsar0 说（60 次点赞、28 条回复、14,785 次浏览、16 次收藏），即便有成年人帮忙写提示词、做上下文工程，编程智能体在他孩子的火箭模拟器和类似科学模拟器任务上仍然失败。令人沮丧的点并不是“智能体从来帮不上忙”；他明确说过，这些工具在维护和扩展训练数据里已有大量模式的软件时很有帮助。真正的缺口，是那些目标行为没那么模板化领域里的通用创造能力。
智能体商业里的信任问题，仍跑在结算基础设施前面¶
严重程度：高。@Onyx_goose 认为（57 次点赞、48 次转发、5 条回复、129 次浏览），智能体商业需要 x402B 式托管，因为自治参与方彼此可能并不认识。@tetsuoai 描述了（86 次点赞、9 条回复、3,976 次浏览、15 次收藏）AgenC 的市场轨道和带证明的交付，一条回复则追问原生的智能体到智能体支付是否已经存在。当前的权宜方案是条件式托管、可审查的工件以及链上协调，但回复区表明，信任问题在工程上仍没跑通。
工具栈正在裂变成技能、记忆、聊天和工作区¶
严重程度：中。@tom_doerr 分享了（22 次点赞、6 条回复、1,751 次浏览、21 次收藏）OpenSkills，回复区马上就在担心，通用技能会不会变成“多工具噩梦”。@mercury__agent 不得不解释（176 次点赞、9 条回复、1,040 次浏览），/code plan 本身不是价值，真正有价值的是那套可追踪的 Git 原生闭环。让人头疼的是可发现性和系统集成：用户想要可复用技能，但不想要上下文膨胀，也不想再多一个孤立运行时。
3. 人们期望的功能¶
企业编程智能体需要真正的负责人和控制平面¶
人们想要的是一套面向 Claude Code 风格落地的务实角色和控制面。@dani_avila7（52 次点赞、21,387 次浏览、58 次收藏）把这个角色叫作 Agent Manager，负责配置、权限、市场选择和约定。机会：直接。这个需求既现实又迫切，因为很多团队在责任归属尚未清晰之前，就已经开始部署智能体了。
既能守住目标、又不让智能体重写验收标准的运行框架¶
@code_rams（5 次点赞、415 次浏览、14 次收藏）想要的是约束、状态、验证、可观测性、洁净状态和行为边界；@nicolasmoute 的回复又补上了规格门控，避免规划器悄悄改写目标。机会：直接。现有运行框架模板已经部分覆盖这个需求，但“规划器重写验收标准”这种失效模式仍需要明确的产品支持。
可信的智能体商业基础轨道¶
@Onyx_goose（57 次点赞、48 次转发）在呼吁 x402B 风格的托管，@tetsuoai（86 次点赞、3,976 次浏览）描述了带证明的交付，@termix_ai（43 次点赞、8,130 次浏览）则给出了显示市场活跃度的成交量指标。机会：直接且竞争激烈。已经有不少项目在同时攻击身份、托管、证明和结算，但回复区仍在追问，支付和验证到底怎么落地。
不只是背着防御提示词的安全智能体¶
@RoundtableSpace（53 次点赞、38,508 次浏览、36 次收藏）给出了一条安全提示词，但回复区说它薄得像纸。@anishathalye（27 次点赞、1,692 次浏览、20 次收藏）在演示提示词注入后，又在讲座里指向能力系统和双 LLM 模式。机会：直接。市场要的是可测试、可执行的安全边界，而不是更小心的措辞。
面向非标准创造性任务的更好基准测试和运行框架¶
@omarsar0（60 次点赞、14,785 次浏览、16 次收藏）把火箭模拟器任务的失败，当成需要通用化运行框架、最终甚至需要原生多模态系统或世界模型的证据。机会：偏愿景。需求是真实存在的，但当前工具看起来更擅长维护和扩展常见软件模式，不擅长创造陌生模拟器。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Learn Harness Engineering | 课程 / 模板 | (+) | 收藏量高；讲状态、验证、可观测性和控制系统；附带模板 | 有回复质疑这到底算不算运行框架工程，而不是偏 ML/PyTorch 的内容 |
| Hermes Agent | 智能体运行时 | (+) | 适合从原型到生产的循环；支持专家智能体迭代 | 纠漂结果未必能迁移到真实生产输入 |
| Claude Code | 编程智能体 / 运行时 | (+/-) | 是运行框架指南、企业落地、技能和本地智能体帖子里的核心工具 | 需要明确归属、配置纪律、权限控制和大上下文 |
| LobeHub Chief Agent Operator | 智能体市场 / 运营层 | (+/-) | 27.3 万技能市场、云端 24/7 执行、IM 回报 | 能否选对智能体，目前更多还是宣称，证据不足 |
| AgenC | 运行时 / 市场 | (+) | 本地守护进程、CLI/TUI/仪表盘、审批、记忆、可观测性、Solana 轨道、ZK/prover 路线 | 回复区仍在质疑是否真正支持原生智能体到智能体支付 |
| x402/x402B | 支付 / 托管 | (+) | 支付轨道加条件式托管，适合自治交易 | 在引用讨论串里仍偏概念；信任模型还需要真正被采用 |
| Mercury Agent | 编程智能体工作区 | (+) | Git 原生的规划 / 执行轨迹、权限加固、SQLite 记忆、token 预算、守护进程模式 | 需要证明更大的工作区闭环不只是多了些规划命令 |
| Gas Town | 多智能体工作区 | (+) | Git 支撑 hooks、Beads 台账、邮箱、身份和交接、声称可协调 20-30 个智能体 | 证据主要来自截图 / README，不是广泛用户报告 |
| OpenSkills | 技能加载器 | (+/-) | GitHub 10,200 星；让 Claude Code 风格技能可跨智能体使用 | 回复区担心上下文膨胀和工具复杂度 |
| Mimeo | 技能生成工具 | (+/-) | 把专家流程转成 SKILL.md/AGENTS.md | 回复区追问它如何区分专家推理和坏习惯 |
| CopilotKit Threads | 智能体应用框架 | (+) | 在 AG-UI 上为任何智能体框架提供可持久化、可恢复对话 | 本次评审里拿不到外部文档；信号主要来自发布推文 |
| Pentest Agents | 安全框架 | (+/-) | 一个拥有 475 星的 Python 漏洞赏金框架，支持多工具和利用链构建器 | 有回复警告，静态脚本如果没有证明可能会幻觉出发现 |
| Cursor Composer 2.5 | 编程模型 | (+/-) | 速度快、价格更低，面向长时间运行的智能体工作 | 测试者说它的智能程度仍落后于 Opus 和 GPT-5.5，还会犯蠢错 |
| ElevenLabs voice agent | 语音 / 公共服务 | (+/-) | 已用于波兰的预约提醒和改期 | 回复区质疑，同样问题是否可以用更便宜的 IVR 解决 |
整体满意度明显分化。只要运行框架、技能和可追踪工作区能减少漂移和重复配置，开发者就会欢迎；但如果工具只是增加上下文负担，或者拿提示词替代可执行的安全边界，反弹也会很快出现。迁移路径已经隐约成形：从原始聊天走向带运行框架的智能体，从一次性技能走向可移植技能，从孤立的编程智能体走向 Git 原生工作区，再从链下协作走向带托管 / 证明的商业基础设施。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Learn Harness Engineering | @_vmlops 分享 | 面向可靠 AI 编程智能体运行框架的课程和模板 | 智能体会丢状态、过早宣告胜利，且缺乏可观测性 | Web 课程、AGENTS.md 风格模板 | Shipped | 课程, 推文 |
| LobeHub Chief Agent Operator | @lobehub | 从技能市场里雇佣智能体，并通过 IM 应用在云端运行 | 手动选择、运行和监控智能体 | 云端智能体市场、IM 集成 | Shipped | 推文 |
| AgenC | @tetsuoai | 智能体运营层，加上市场、结算和带证明的交付 | 自治工作需要执行、审查、支付和信任轨道 | 本地守护进程、CLI/TUI/web、Solana、ZK/prover | Beta | 推文 |
| Mercury Agent | @mercury__agent | 带权限控制的编程智能体，采用 Git 原生工作流并带记忆 | “和代码聊天”缺少可追踪的规划和受控执行 | TypeScript、SQLite、CLI/Telegram | Shipped | GitHub, 推文 |
| Gas Town | @GithubProjects 分享 | 多智能体工作区管理器 | 多个智能体会丢失上下文、交接和工作状态 | Git 支撑 hooks、Beads 台账 | Shipped | 推文 |
| OpenSkills | @tom_doerr 分享 | Claude Code 风格技能的通用加载器 | 技能被困在单一智能体生态里 | TypeScript、SKILL.md、AGENTS.md | Shipped | GitHub, 推文 |
| Mimeo | @tom_doerr 分享 | 把专家思路转成 SKILL.md 或 AGENTS.md | 专家工作流很难为智能体打包 | Python | Alpha | GitHub, 推文 |
| CopilotKit Threads | @CopilotKit | 面向智能体应用的可持久化、可恢复对话 | 用户需要在应用里拥有类似 ChatGPT 的连续性 | AG-UI、CopilotKit | Shipped | 文档, 推文 |
| Pentest Agents | @DarkWebInformer 分享 | 面向多种编程智能体的自治漏洞赏金框架 | 安全测试需要可重复的智能体工作流 | Python、Claude Code/Codex/Gemini/Cursor/Windsurf/Copilot/OpenClaw | Alpha | GitHub, 推文 |
| $CLAWD/Larv AI governance | @clawdbotatg | 由训练出的小型智能体替质押者投治理票 | DAO 投票者没有时间持续跟进信息 | 链上质押、AI 治理、私密推理 | Beta | 网站, 推文 |
反复出现的构建模式，是让智能体在运营上看得见、管得住。不少项目都在把工作打包成能跨会话或跨工具延续的东西，另一些则把同样的需求延伸到商业和治理：智能体需要结算、声誉、证明和审查。许多项目的薄弱点，都是在脏乱真实使用场景下如何证明可靠性——这正体现在关于漂移、提示词注入、渗透测试幻觉发现和上下文膨胀的回复里。
6. 新动态与亮点¶
波兰医疗语音智能体落地¶
@mati 表示（1,113 次点赞、47 条回复、20 条引用、64,986 次浏览、153 次收藏），波兰正在为 Centralna e-Rejestracja 推出由 ElevenLabs 驱动的语音智能体，它会给只能接听座机的患者打电话，提醒预约时间，并协助改期。这个运营层面的说法很具体：每年 4,000 万次预约，爽约率在 10-20% 之间。回复区分成两派：一派说“爽约是最大的问题之一”，另一派则质疑，相比更广泛的医疗排队问题，政府是否应该优先投入 AI。
Bankr 生态图¶
@BaseHubHB 发布了（140 次点赞、31 条回复、7,968 次浏览、57 次收藏）一张 Bankr 生态图，覆盖智能体基础设施、网络、RWA、隐私、声誉、构建者工具、交易、游戏和智能体人设。它之所以值得注意，是因为链上智能体项目已经开始分化成可辨认的类别，而不再只是一整个“AI 币”篮子。
智能体经济的治理担忧被套上“黑箱”框架¶
@kimmonismus 重点提到（49 次点赞、6 条回复、11,600 次浏览）Patrick Hussey 的《The Agentic Economy Has No Black Box》，并说智能体已经在破坏生产系统、无视停止命令，还在模拟中维持合谋定价。配图的副标题——“跨参与方的智能体失效，以及尚不存在的公民基础设施”——把当天的治理讨论从单家公司安全，扩展到了更大的制度层面。
串行编排优先于蜂群¶
@pvncher 认为（23 次点赞、4 条回复、3,017 次浏览、12 次收藏），由管理模型编排、并给子智能体划清作用域的方式，比“智能体蜂群”更强。真正关键的是他的回复：智能体之间任意传消息，只会把它们带偏；并行最适合只读工作，写入任务则需要加锁和验证。
7. 机会在哪里¶
[+++] 企业级智能体控制平面 —— 证据来自 @dani_avila7 的 Agent Manager 角色、@code_rams 的运行框架组件、@shannholmberg 的部署闭环，以及 @_vmlops 的课程。这个机会很强，因为痛点是运营层面的、反复出现的，而且已经和企业落地直接绑定。
[+++] 具备可执行边界的智能体安全 —— 证据包括 @anishathalye 的提示词注入演示、@RoundtableSpace 那场关于提示词防御的争论，以及 @DarkWebInformer 的 Pentest 框架与围绕幻觉的批评。这个机会很强，因为只靠提示词的方案已经被公开地不信任。
[+++] 面向智能体商业的信任、托管与证明 —— @Onyx_goose、@tetsuoai、@termix_ai 和 @clawdbotatg 都在指向结算和验证。机会很强，因为项目已经开始交易，但回复区仍在追问信任和支付如何被真正执行。
[++] 可移植的技能与记忆基础设施 —— OpenSkills、Mimeo、Mercury Agent 和 CopilotKit Threads 都在尝试让能力跨会话、跨应用或跨智能体延续。这个机会中等，因为需求很清晰，但上下文膨胀和技能质量仍未解决。
[++] 多智能体工作区协作 —— Gas Town、Mercury 和 @pvncher 对编排的评论，都说明市场需要有作用域的子智能体、交接、锁和验证。这个机会中等，因为构建者已经在出货，但这些宣称还需要在更大团队里被验证。
[+] OOD 创造性智能体评估 —— @omarsar0 的火箭模拟器失败，说明基准测试和运行框架仍有一块空白：它们需要测试的不只是常见应用模式。这个机会还在浮现，因为证据质量高，但仍只集中在单条讨论串里。
8. 要点总结¶
- 运行框架工程再次成为最核心的智能体话题，但它正在变成组织级基础设施。 当天最强的证据，是一门被大量收藏的课程、一个 Hermes 部署闭环、一份设计指南，以及一个 Agent Manager 落地角色的组合。 (来源)
- 智能体商业正在从叙事走向基础轨道。 AgenC、x402B、TermiX 和 $CLAWD 谈的都已经是执行、结算、托管、证明或治理指标，而不只是“智能体会交易”。 (来源)
- 可移植技能很有吸引力，但也带来风险。 OpenSkills 跨智能体的 SKILL.md 模型引起了兴趣，同时回复区也在警告工具复杂度和上下文窗口会把技能吞掉。 (来源)
- 安全宣称需要证据。 一条安全提示词立刻遭到质疑，而 MIT 讲座又演示了针对 Opus 4.6 的提示词注入，让智能体安全继续停留在“尚未解决的问题”这一类。 (来源)
- 当前的编程智能体在某些创造性、样本稀少的任务上仍然会失败。 火箭模拟器讨论串成了企业成功叙事的一种有用制衡，因为它描述的是即便加上提示词和上下文辅助，失败仍一再发生。 (来源)
- 当前构建者的共同模式，是可追踪性。 Mercury、Gas Town、CopilotKit Threads 和 Mimeo 都在保留状态、技能、对话或工作痕迹，让智能体不再像一次性聊天窗口。 (来源)