Twitter AI 智能体 - 2026-06-21¶
1. 人们在讨论什么¶
1.1 运行框架工程继续从口号走向操作系统 (🡒)¶
最强的一组讨论仍然围绕模型之外的控制层展开，但 6 月 21 日又把它进一步推进成了公开、可检查的具体产物：课程、模式目录、可强制执行的 hooks，以及那些已经在多个智能体之间分派工作的操作者笔记。至少有 5 条强信号支撑了这一主题。
@rohanpaul_ai 引用了 Aravind Srinivas 的说法（109 点赞，8 回复，8,509 浏览，63 收藏）：Codex、Perplexity Computer 和 Claude Code 是编排系统加上智能体运行框架的组合，而不只是模型封装器。这一点之所以重要，是因为当天剩余的内容都给出了这种运行框架的具体形态：课程材料、可复用模式，以及运行时强制机制。
@rohit_tiwari 提到了《Learn Harness Engineering》（62 点赞，4 回复，2,263 浏览，73 收藏），把这项工作定义为面向 Claude Code 和 Codex 的智能体环境设计、状态管理、验证、控制系统，以及可靠工作流。
@DanKornas 分享了 AI Development Patterns（17 点赞，3 回复，972 浏览，15 收藏），而公开的 AI Development Patterns 仓库 描述了覆盖基础、开发和运维 3 个层面的 24 种模式，并明确将其映射到运行框架工程中的前馈与反馈控制。这个仓库把原本常被当作“品味”来讨论的东西，转化为一连串具体的采用选择，比如安全沙箱、规格驱动开发、并行智能体、上下文持久化和自主修复。
@sudoingX 描述了一个实时运行的配置（70 点赞，10 回复，4,099 浏览，72 收藏）：3 台机器上跑着 4-6 个智能体，前沿模型负责困难的架构工作，本地 Hermes Agent 承担大部分重构、草稿和研究轮次。最有辨识度的细节不是模型本身，而是围绕模型的操作栈：用 tmux 保持持久性、用 SSH 网状连接保证可达性、用 Git 仓库充当共享记忆。在回复里，有读者说最难解决的问题仍然是写冲突、按智能体划分角色、模型选择，以及 Git worktree 合并。
@DanKornas 重点介绍了 Harmonist（15 点赞，3 回复，1,066 浏览，23 收藏），公开的 Harmonist 仓库 写明，如果所需 reviewer 没有执行、记忆没有更新，或完整性检查失败，那么会通过机械方式直接拦下会改代码的轮次。这个说法比单靠提示词纪律更进一步：该仓库把协议强制定位为 hook 层面的闸门，而不是模型可以忽略的一条指令。
讨论要点： 回复里真正关心的已经不是抽象的“更好的提示词”，而是那些仍未解决的协同问题：写冲突、角色分配、模型路由，以及如何强制执行 review 和记忆更新，而不是只是在提示词里要求它们这么做。
与前日对比： 6 月 20 日的讨论还更宽泛，主要围绕循环、上下文层和 harness。到了 6 月 21 日，主题没变，但重心转向了公开产物：一门课程、一个模式目录，以及一个核心主张是“智能体不能跳过规则”的仓库。
1.2 Skills、Markdown 仓库和治理层本身开始成为产品 (🡕)¶
第二个主题是：行为层如今正被直接打包和分发，而围绕这些层的安全与治理工作本身也开始变成一个独立的产品类别。至少有 4 条强信号支撑了这一主题。
@alex_prompter 整理了一份高星 GitHub 仓库列表（72 点赞，10 回复，5,259 浏览，128 收藏），这些仓库的核心载荷不是运行时代码，而是 Markdown、skills 和提示词集合。尽管带有宣传色彩，但这条帖子捕捉到了一个真实趋势：如今被分享的产物，往往已经是行为层本身。
@simplifyinAI 提到了 NVIDIA 的 SkillSpector（15 点赞，2 回复，605 浏览，11 收藏），这是一个面向 AI 智能体 skills 的扫描器。仓库写明它会检查 16 个类别中的 64 种漏洞模式，并引用研究称 26.1% 的 skills 含有漏洞，5.2% 显示出可能的恶意意图。这为“在安装第三方 skills 前，生态系统现在默认需要先做审查”提供了很强的证据。
@sytaylor 强调了 Santander 新发布的开源 AI 项目（58 点赞，6,528 浏览，78 收藏），公开的 SantanderAI GitHub 组织 现在列出了 autoguardrails、llm_bridge、mech-gov-framework、mutatis-mutandis、stressed datasets、gen-fraud-graph 等控制层项目。这些 README 把范围写得很具体：autoguardrails 在单一的 policy.md 表面上、针对固定评测集做搜索，而 mech-gov-framework 则为高风险决策强制执行硬闸门和治理指标。
@Dagnum_PI 认为（32 点赞，3 回复，924 浏览），现有的银行模型风险指引仍然无法适配生成式或智能体式 AI，而这正是这些扫描器和治理框架试图补上的缺口。
讨论要点： 这场讨论越来越把 skills 和提示词当作可安装的供应链，而不再是无害文本。这也解释了为什么当天构建者的精力分成了两路：一边分享新的 skill 包，一边围绕它们构建扫描器、manifest 和治理框架。
与前日对比： 6 月 20 日已经显现出纯行为仓库在升温。6 月 21 日则增加了更硬的一面：供应链验证、skill 扫描，以及一家银行公开发布自己的治理技术栈。
1.3 耐久的私有运行时比单纯的演示魔法更重要 (🡖)¶
第三个主题是，人们评判智能体运行时，看的越来越是它能否存活、恢复、调度工作，并让有用的上下文持续存在。整体情绪依然偏正面，但最强证据关注的是耐久性和运维，而不是新奇感。
@acoyfellow 发布了 My AX（8 点赞，7 回复，1,480 浏览，18 收藏），将其定位为部署在用户 Cloudflare 账户中的单操作者运行时，支持持久会话、自带 MCP 工具、周期性任务、有边界的子智能体，以及保留下来的输出。公开的 My AX repo 补上了这条推文只是略微提及的运维细节：明确的委派深度限制、定时任务、工作区快照，以及部署边界。
@openclaw 宣布发布 OpenClaw v2026.6.9（94 点赞，11 回复，8,296 浏览），带来更稳定的智能体恢复、更强的 Codex 集成、更轻的分发包，以及搜索/skills 改进。讨论串里的回复把这份发布说明具体化了：重试、会话历史修复、回复对齐，以及插件自动批准。
@ScottyBeamIO 描述了一个 Hermes Agent 配置（99 点赞，37 回复，6,266 浏览，88 收藏）：它先起草 iMessage 回复，再从草稿与用户实际回复之间的差距中学习。技术上真正有意思的地方不只是个性化这个说法，而是它的训练闭环：真实消息历史成了监督信号。
@GoogleCloudTech 分享了一个生产案例（41 点赞，1 回复，4,154 浏览，14 收藏）：专门化的多智能体系统把大型 TensorFlow 模型迁移到了 JAX。关联的 Google Cloud 文章 说，这套系统使用了分层 Playbooks 以及定量、定性验证，并在复杂的 YouTube 模型迁移上报告了 6.4x-8x 的加速。
讨论要点： 最强的运行时帖子都有同一个潜台词：难点已经不再是让智能体把一件惊艳的事做成一次，而是如何通过恢复、周期性、人类边界和显式验证，让它长期保持有用。
与前日对比： 6 月 20 日更关注智能体跨越手机、设备和消息系统等不同表面。到 6 月 21 日，视角收窄到了持久性、恢复能力和企业级验证。
2. 令人困扰的问题¶
多智能体工作流的故障点仍在协同，而不是模型原始质量¶
严重程度：高。 @sudoingX 描述了一个可运行的多智能体配置（70 点赞，10 回复，4,099 浏览，72 收藏），但最有价值的一条回复立刻点出了尚未解决的瓶颈：写冲突、按智能体划分角色、按任务选择模型，以及 Git worktree 合并。@rohanpaul_ai 引用时也用更简短的形式给出了同样诊断（109 点赞，8 回复，8,509 浏览，63 收藏）：产品是编排系统加运行框架，而不只是模型本身。@DanKornas 回应了这一点（17 点赞，3 回复，972 浏览，15 收藏），发布了一个模式目录，因为团队仍然需要一种方法，把临时拼凑的智能体使用方式变成可重复的工作流。今天的应对策略就是显式脚手架：模式、hooks、共享仓库，以及更收窄的角色划分。
信任与合规仍然落后于真实的智能体部署¶
严重程度：高。 @Dagnum_PI 表示（32 点赞，3 回复，924 浏览），Federal Reserve、OCC 和 FDIC 仍然没有适用于生成式或智能体式 AI 在受监管工作流中做决策的审计框架。@sytaylor 强调了 Santander 对这个缺口的回应（58 点赞，6,528 浏览，78 收藏）：围绕安全护栏、治理、鲁棒性和供应商中立模型访问的公开仓库。@simplifyinAI 补充了一个更战术层面的信号（15 点赞，2 回复，605 浏览，11 收藏）：NVIDIA SkillSpector 的仓库称，超过四分之一的已扫描 skills 含有漏洞。这个方向值得构建，因为痛点并非理论上的：在人们为如何建立信任制定标准之前，行为层产物就已经在被更快地分发和安装。
智能体可靠性和产品质量仍然需要持续维护¶
严重程度：中。 @openclaw 发布了一个版本（94 点赞，11 回复，8,296 浏览），重点处理各种细碎问题、更稳定的恢复能力，以及会话修复——这本身就说明，长时间运行的运行时仍会在日常场景里频繁出故障。@Pragmatic_Eng 引用了 Dax Raad 的说法（51 点赞，1 回复，27,675 浏览，30 收藏）：产品“腐烂得比以往更快”，因为智能体工作流让团队更容易交付低质量成果，除非他们持续把质量投入当成日常实践。当前的绕行方案不是再讲更多模型神话，而是更好的恢复路径、更强的终端 UX，以及更明确的 review 和验证层。
3. 人们期望的功能¶
团队无需从零发明、可直接采用且可检查的运行框架¶
最清晰、最现实的需求，是为 AI 辅助开发提供可复用的结构。@rohit_tiwari 分享了一门免费的运行框架工程课程（62 点赞，4 回复，2,263 浏览，73 收藏）；@DanKornas 发布了一个 24 模式目录（17 点赞，3 回复，972 浏览，15 收藏）；@alex_prompter 展示出纯行为仓库如今本身就能吸引大量 star（72 点赞，10 回复，5,259 浏览，128 收藏）。这种诉求是现实的，不是愿景式的：团队想要的是能检查、复制并持续演化的现成方法手册。机会：直接。
面向 skills、review 和高风险决策的机械化信任层¶
第二类需求是：系统要能证明智能体确实遵守了协议，而不只是声称自己遵守了。@DanKornas 重点介绍了 Harmonist 基于 hook 的停止闸门（15 点赞，3 回复，1,066 浏览，23 收藏）；@simplifyinAI 提到了 SkillSpector 这个安装前扫描器（15 点赞，2 回复，605 浏览，11 收藏）；@Dagnum_PI 描述了围绕智能体决策的监管缺口（32 点赞，3 回复，924 浏览）。Santander 的公开仓库今天已经给出了一部分答案，但底层需求仍然大面积未被满足。机会：直接。
让记忆、任务和工具始终处于操作者控制之下的耐久私有运行时¶
运行时层面的愿望并不只是“更自主的智能体”，而是带着持久性与边界的自主性。@acoyfellow 展示了 My AX（8 点赞，7 回复，1,480 浏览，18 收藏），把它定义为部署在 Cloudflare 上、具有持久会话和周期性任务的个人运行时；与此同时，@sudoingX 使用本地 Hermes Agent 处理私密的夜间工作（70 点赞，10 回复，4,099 浏览，72 收藏）。这种诉求很现实，但市场大概率会很拥挤，因为所有认真的运行时构建者都在朝持久化、调度以及本地或操作者自有状态收敛。机会：竞争激烈。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编程智能体 | (+) | 围绕循环、skills 和运行框架设计的核心参照物；多次被当作其他系统封装的基础运行时 | 信息流反复表明，如果没有运行框架、hooks 和记忆纪律，单靠原始提示词远远不够 |
| Hermes Agent | 智能体运行时 | (+/-) | 适合本地/私有的大批量工作、消息个性化和常驻自动化 | 回复暴露出写冲突、角色分配和路由等尚未解决的协同问题 |
| OpenClaw | 智能体运行时 | (+) | 围绕恢复、Telegram 交付、搜索和更强的 Codex 集成保持活跃发布节奏 | 这次发布本身就说明，可靠性和细碎问题仍需要持续修补 |
| Harmonist | 编排框架 | (+) | 机械式停止闸门、记忆检查和供应链验证，把强制执行从提示词里移了出来 | 比轻量提示词包更强调运维立场；仍属于早期采用者工具 |
| AI Development Patterns | 工作流目录 | (+) | 为团队提供一张跨准备度、开发和运维的 24 模式采用地图 | 它提供的是文档和结构，本身并不负责强制执行 |
| SkillSpector | 安全扫描器 | (+) | 对 skills、仓库、URL 和文件扫描 64 种漏洞模式，并给出明确风险分数 | 关注的是安装时的 skill 风险，而不是完整运行时行为 |
| autoguardrails | Guardrail 运行框架 | (+) | 固定评测集、单一可变的 policy.md 表面，以及 ASR 跟踪，构成了一个干净的研究闭环 |
范围较窄：更像单轮 guardrail 实验，而不是完整智能体工作流 |
| mech-gov-framework | 治理框架 | (+) | 硬闸门、歧义检查、治理指标，以及供应商中立的后端支持 | 面向合成高风险决策场景，因此生产采用仍偏早期 |
| llm_bridge | LLM 基础设施 | (+) | 通过统一接口接入 OpenAI、Bedrock、Gemini 或自定义后端，降低提供商锁定 | 它解决的是后端切换，不是编排或信任问题本身 |
| My AX | 个人运行时 | (+/-) | 持久会话、周期性任务、自带 MCP 工具，以及明确的运维边界 | 仓库明确说它仍属实验性且部署负担较重，许多边界仍需操作者自行管理 |
整体满意度光谱，对显式系统偏正面，对一次性提示词则更为复杂。人们最认可的，是那些把模型外控制层讲清楚的工具：模式、hooks、manifests、闸门，或可重复的运行时边界。最清晰的迁移路径是：把前沿模型用在高难度推理工作上，同时把大批量或周期性工作推向本地或更低成本的运行时，并将模型后端与让它可靠的运行框架分离开来。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Harmonist | @DanKornas | 用 hooks 强制执行 review、记忆和完整性规则的可移植编排包 | 防止编程智能体悄悄跳过必需的工作流步骤 | Python stdlib、bash、IDE hooks、manifests | Beta | 推文, 仓库 |
| AI Development Patterns | @DanKornas | 收录 24 种 AI 辅助开发模式的开放目录 | 为团队提供从临时使用智能体走向结构化工作流设计的可重复路径 | Markdown 文档、生命周期框架、运行框架工程视角 | Shipped | 推文, 仓库 |
| SkillSpector | @simplifyinAI | 在安装前扫描智能体 skills 中的漏洞和恶意模式 | 为快速增长的 skill 供应链增加审查环节 | Python 3.12+、静态分析、可选 LLM 分析 | Shipped | 推文, 仓库 |
| autoguardrails | Santander AI | 在固定评测集上搜索 policy.md，以改进 guardrails |
为团队迭代拒答和越狱策略提供紧凑的研究运行框架 | Python、固定评测集、ASR 日志 | Alpha | 推文, 仓库 |
| mech-gov-framework | Santander AI | 对高风险 LLM 决策执行并衡量治理 | 为受监管决策流创建可审计的闸门和指标 | Python、硬闸门、治理指标、合成银行数据集 | Alpha | 推文, 仓库 |
| llm_bridge | Santander AI | 供应商中立的 LLM 客户端库 | 让团队无需重写应用代码就能切换模型提供商 | Python、OpenAI/Bedrock/Gemini adapters | Shipped | 推文, 仓库 |
| My AX | @acoyfellow | 部署在用户 Cloudflare 账户中的单操作者个人运行时 | 让持久任务、工具和会话状态始终处于操作者控制之下 | Cloudflare Workers、D1、KV、R2、MCP、Browser Run | Alpha | 推文, 仓库 |
| OpenClaw v2026.6.9 | @openclaw | 聚焦恢复、skills、搜索和 Codex 集成的运行时版本更新 | 减少长时间运行的智能体会话中的运维摩擦 | OpenClaw runtime、Telegram、Codex integration | Shipped | 推文, 发布说明 |
| Tiny Place | @tinyhumansai | 让智能体发现赏金、协商并以 USDC 结算的市场界面 | 为智能体提供直接的赚钱与交易层 | Solana、x402、Phantom、本地智能体栈 | Beta | 推文 |
Santander 这一组是最清晰的构建者信号，因为它不是单个仓库，而是一整套控制层组合：guardrails、机械治理、模型抽象、公平性测试、stressed datasets，以及 fraud-graph generation，全都放在同一个公开组织下。这套组合读起来不像副项目，更像一家受监管机构把内部 AI 脚手架公开发布出来。
Harmonist、AI Development Patterns 和 SkillSpector 从另一个角度展示了同样的模式：团队不再只是在构建智能体，他们也在构建围绕智能体的纪律体系。一个仓库把方法手册编码化，一个负责强制执行协议，一个负责扫描可安装的 skill 供应链。
My AX 和 OpenClaw 则代表了运行时这一侧。它们之所以值得注意，都不是因为新奇演示，而是因为强调了耐久运维——任务、恢复、保留状态和有边界的执行。Tiny Place 是一个异类，它通过给智能体提供协商和结算工作的场所，让智能体商业化这条线程继续活跃。
6. 新动态与亮点¶
一家大型银行开源了自己的 AI 控制层¶
@sytaylor 提到了 Santander 面向 AI 工具的新 GitHub 组织（58 点赞，6,528 浏览，78 收藏），公开的 SantanderAI organization 现在展示出一整组围绕安全护栏、治理、鲁棒性、公平性、欺诈基准测试和后端抽象的仓库。真正值得注意的地方不只是某一个仓库上线，而是：一家受监管机构以开源许可证公开了自己 AI 控制栈中的多个组成部分，并明确说明只发布合成或匿名化数据。
专门化的多智能体系统展示了一个具体的企业级胜利¶
@GoogleCloudTech 报道称，Google 用专门化的多智能体系统把生产中的 TensorFlow 模型迁移到了 JAX（41 点赞，1 回复，4,154 浏览，14 收藏）。关联的 Google Cloud 文章 说，分层 Playbooks、数学验证和 LLM-judge review 在复杂的 YouTube 模型上带来了 6.4x-8x 的报告加速，使这成为当天最清晰的企业部署信号之一。
7. 机会在哪里¶
[+++] 智能体治理与协议强制执行 —— 证据同时来自多个部分：Harmonist 把必需的 review 和记忆更新变成机械闸门；SkillSpector 把 skills 视为高风险安装表面；Santander 开源了 guardrail 和治理仓库；而 @Dagnum_PI 描述了受监管工作流中智能体决策仍然存在的审计缺口。这个机会之所以强，是因为痛点同时体现在实际使用、合规压力和开源构建活动中。
[++] 耐久的私有多智能体运维 —— My AX、OpenClaw、Hermes Agent 工作流，以及 sudoingX 的本地多机配置，都指向同一种需求：能保持状态、干净恢复、调度工作，并始终处于操作者控制之下的智能体。这个机会属于中等强度，因为需求很明确，但已经有多个构建者在向这里收敛。
[+] 专门化的迁移与现代化智能体 —— Google 的 TF-to-JAX 迁移系统表明，只要具备强 Playbooks 和验证闭环，专门化的智能体栈已经能加速高难度代码转换工作。这个机会仍在浮现，因为信号很强，但目前还主要集中在一个公开的企业案例上，而不是一组广泛可比的部署。
8. 要点总结¶
- 围绕智能体的讨论继续从提示词技巧转向运行框架设计。 当天最强的产物是一门课程、一个模式仓库、一个由 hook 强制执行的框架，以及关于如何在多个智能体之间分派工作的操作者笔记。(来源)
- Skills 和 Markdown 仓库如今被当作软件供应链，而不是无害文本。 以 skills 为核心的仓库列表、SkillSpector 的扫描器，以及 Harmonist 的 manifest 检查组合在一起，说明行为层现在已经是团队预期会安装并审计的东西。(来源)
- 面向智能体系统的治理正在成为一个可见的构建类别。 Santander 的开源组合，以及聚焦银行领域声音对监管缺口的抱怨，都表明围绕 AI 决策的可审计控制层需求正在上升。(来源)
- 胜出的运行时故事都关乎耐久性，而不是 spectacle。 My AX、OpenClaw、Hermes 的个性化能力，以及 Google 的迁移系统，都更强调持久性、恢复能力或验证，而不是一次性演示。(来源)