Twitter AI 智能体 - 2026-06-25¶
1. 人们在讨论什么¶
1.1 循环工程成为一门明确的架构学科 (🡕)¶
最核心的讨论已经不再只是“循环很重要”。大家开始讨论循环里到底必须包含什么：触发器、独立校验器、外部状态、作用域清晰的 worker、证明机制，以及终止规则。至少有 4 条高信号内容支撑了这一主题。
@akshay_pachaar 认为（998 点赞、44 回复、129,289 浏览、1,690 收藏）除非把触发器、maker-checker 分离、磁盘持久化状态、停止条件和可观测性都移进系统里，否则人类仍然是瓶颈。他点名 Graphiti 作为状态层、Opik 作为 tracing 层，让这条帖子不只是关于自主性的口号。
@cwolferesearch 将（43 点赞、2 回复、1,886 浏览、43 收藏）智能体定义为处在智能体式循环中的 LLM，并给出测试框架的 4 个组成部分：backbone、instructions、tools 和 environment，外加明确的终止检查。配图让这个观点更具体——它展示了上下文管理和记忆在测试框架中的位置，而不是把它们当成提示词细节处理。
@0xCodez 传播了（75 点赞、17 回复、7,086 浏览、70 收藏）Anthropic 的 《Building Effective AI Agents: Architecture Patterns and Implementation Frameworks》，总结了单智能体、顺序、并行、分层，以及 evaluator-optimizer 等模式。Anthropic 自己的公开资源页也确认，这份指南的重点是单智能体设计、多智能体编排和生产示例，而不是泛泛的提示词建议。
@DerekNee 反驳了（33 点赞、5 回复、1,908 浏览、42 收藏）“一个拥有所有工具和所有文件的巨型智能体”这种思路，转而提出 Matrix“公司操作系统”：工作区大脑、部门负责人、作用域清晰的执行者，以及证明闭环。这是当天最清晰的信号之一，说明争论已经从“我要不要用智能体？”转向“我该如何组织这种自治体系，既有组织级自主性，又不丢掉问责？”
讨论要点：最强烈的回复都在谈失败模式。Akshay 讨论串下的一条回复说，真正不变的约束是要把目标、状态、证据和退出标准保存在模型之外；而 Derek Nee 的一条回复则指出，工具列表一旦过长，模型就会在循环中途开始漏掉调用。
与前日对比：6 月 24 日已经高度聚焦循环、技能和状态。到 6 月 25 日，讨论又往前推进了一步，开始明确测试框架组件、以验证为核心的组织设计，以及公开发布的架构指南。
1.2 技能和记忆不再只是零散提示词，而成了可复用的运行层 (🡕)¶
第二个主题是封装。人们分享的不再只是提示词，而是把工作流、库知识、UI 审美和记忆打包成可安装、可跨会话存续的工件。至少有 5 条高信号内容支撑了这一主题。
@akshay_pachaar 解释了（36 点赞、2 回复、5,124 浏览、39 收藏）Hermes Agent 新的 /learn 流程：只要把文档 URL、SDK 目录、walkthrough 或笔记交给智能体，它就会产出一个经过测试的 SKILL.md，之后可以作为 slash command 调用。他在讨论串里强调的关键区别是，这让技能创建提前到了工作流前端，而不是等智能体反复失败后才“学会”这一课。
@aiedge_ 推荐了（130 点赞、10 回复、11,963 浏览、240 收藏）Taste Skill，其公开网站和仓库将它描述为一个面向布局、排版、动效和留白的反模板化前端技能包。回复里给出了重要但书：这些风格约束在多步工具调用中可能会漂移，而且在 Hermes、Claude Code 和 Codex 之间的迁移效果也未必一致。
@tiangolo 发布了（23 点赞、1 回复、1,246 浏览、10 收藏）Library Skills，让库随包一起发布官方智能体技能，并与版本发布保持同步更新。公开文档写明，安装器会扫描项目依赖、添加受管理的符号链接，并明确推荐 Claude Code 使用 .claude/skills。
@tom_doerr 提到了（7 点赞、1 回复、2,910 浏览、15 收藏）Continuous-Claude-v3。其 README 将它定位为持久化的 Claude Code 环境，包含 YAML handoff、daemon 提取的学习、109 个技能、32 个智能体和 30 个 hook。这个栈比一个简单提示词文件重得多，但也说明了开发者为了把上下文连续性变成系统行为，已经愿意堆多少层基础设施。
@kevincodex 发布了（27 点赞、4 回复、986 浏览）memlawb，一个面向智能体的零知识记忆层。其公开仓库写明，记忆会在客户端用 AES-256-GCM 加密、只以密文形式同步，并以 memory_save、memory_recall、memory_search 等 MCP 工具对外提供。
讨论要点：最有价值的怀疑集中在维护，而不是创建。一条 /learn 讨论串下的回复追问，当工具或约束变化时，谁来标记技能已过时；而 Taste Skill 的回复则在问，风格是否真的能在长时间的工具使用过程中保持稳定。
与前日对比：6 月 24 日强调的是技能作为可复用工作流包。到 6 月 25 日，讨论进一步转向从源材料自动生成技能、与依赖发布同步的库级指导，以及作为专门基础设施的隐私保护型记忆。
1.3 智能体商业正在围绕路由、付费数据和受治理访问来拼装 (🡕)¶
第三个主题是，商业化正在沿着基础设施层展开。商业侧最强的帖子都在讨论，如何让智能体接上正确的数据、正确的模型和正确的支付通道，而不必逼着开发者每次都重造这些层。至少有 4 条保留下来的内容支撑了这一主题。
@austinh___ 提到（247 点赞、58 回复、280,568 浏览、198 收藏），他的团队为外呼销售搭建了一个基于 Claude 的产品，连接 40+ 数据源，在最初几周就跑出了 57,548 次 beta 查询和 45% 的周环比增长。最强的信号不只是这个概念本身，而是垂直工作流与公开早期使用数据的结合。
@WilliamBryk 将（185 点赞、14 回复、45,966 浏览、112 收藏）Exa Connect 描述为智能体的新市场结构：数据提供方设定价格，开发者选择让自己的智能体使用哪些专有数据源。被引用的 Exa 发布帖点名了 ZoomInfo、Crunchbase、Similarweb 等提供方，而回复里立刻有人追问，新提供方要怎么加入这个市场。
@ampersend_ai 解释了（10 点赞、1 回复、661 浏览、4 收藏），他们在 Amazon Bedrock AgentCore Payments 之上做了一层按智能计费的路由层。配套的 AWS 文章 《Building pay-per-intelligence for AI agents》 证实了这种两跳式设计：智能体先通过 AgentCore 向 Ampersend 付款，再由 Ampersend 与上游提供商结算，从而避免逐个提供商处理计费和钱包逻辑。
@StudentOffersHQ 发布了（40 点赞、7 回复、1,746 浏览、54 收藏）Zyloo 的截图，展示单个 OpenAI 兼容端点后面挂着 27+ 个模型，并临时免费开放 Claude Sonnet 4.6 和 GPT-5.4。这条帖子的技术深度不如 Exa 和 Ampersend，但它仍然强化了当天更广泛的模式：模型访问正被统一网关和定价层抽象掉。
讨论要点：回复不断回到供给和限制，而不是模型质量本身。Exa 的回复在问怎样成为数据提供方合作伙伴；Zyloo 的回复则立刻追问限流和实际使用约束。
与前日对比：6 月 24 日展示的是智能体向销售、研究、支付和云运维扩展。到 6 月 25 日，焦点收窄到支撑这些场景的“轨道”——专有数据市场、托管支付流，以及“一把钥匙”式的模型路由。
2. 令人困扰的问题¶
长时任务一旦由单个智能体承担过多职责，仍然会崩¶
严重程度：高。@akshay_pachaar 表示（998 点赞、44 回复、129,289 浏览、1,690 收藏），除非把调度者和检查者的角色移进系统里，否则人类仍然是调度器和校验器，而且状态必须落在磁盘上，而不是留在上下文中。@DerekNee 认为（33 点赞、5 回复、1,908 浏览、42 收藏），“一个拥有所有工具、所有文件、却没有任何问责的巨型智能体”不是自主性，而是一台造雾机。他在回复中把失败模式说得更尖锐：工具太多会让模型开始漏掉调用，而那些难看的生产工作依然需要有人真正负责。这个方向值得构建，因为这种抱怨同时出现在高互动量的循环讨论串和具体的组织架构方案里。
技能创建更容易了，但技能发现与维护依然混乱¶
严重程度：高。@akshay_pachaar 展示了 Hermes 现在可以根据文档或笔记生成一个经过测试的技能，但点赞最多的回复立刻追问：当世界变了，谁来判定这个技能已经过时。@DanKornas 说（8 点赞、2 回复、1,066 浏览、4 收藏），Claude skills 确实有用，但要找到合适的技能仍然很乱，所以他重点推荐的是一份整理过的清单，而不是另一个单独的技能。@aiedge_ 带出了 一个引发强烈兴趣的设计技能，但回复质疑这些风格规则是否能穿过工具调用、是否能跨模型迁移。当前的权宜方案是策展、版本管理，以及像 Library Skills 这样由官方库支撑的技能，但治理问题仍未解决。
数据、模型和支付这几层 plumbing 仍然吞掉太多工程时间¶
严重程度：高。@ampersend_ai 直接说清了（10 点赞、1 回复、661 浏览、4 收藏）这种基础设施税：如果没有托管层，开发者在智能体逻辑上线之前，就得先把钱包管理、签名、x402 处理、花费控制，以及按提供商分别计费这些基础工作搭起来。@WilliamBryk 把 Exa Connect 作为数据侧的权宜方案——让提供方为智能体消费的专有数据集定价；而回复表明，开发者和数据供应方都需要一条干净的市场接入路径。哪怕是像 @StudentOffersHQ 发布 Zyloo 截图这样轻量的网关案例，也很快引来了关于限流的问题。这个方向值得做，因为同样的抱怨同时出现在付费模型、付费数据和多模型路由上。
3. 人们期望的功能¶
能从源材料自动生成、并持续保持新鲜的技能¶
最明确的现实需求，是建立一条可靠管线，把“这是事实来源”直接变成“这是可复用技能”。@akshay_pachaar 把 Hermes /learn 描述成这样一个入口，而 @tiangolo 展示了 Library Skills 作为同一思路在包维护者侧的版本——技能会随库版本发布而同步更新。@DanKornas 补充说，即便技能已经存在，发现它们仍然很混乱。机会：直接。
能跨会话存活、又不会变成另一类信任问题的持久记忆¶
人们也想要持久性，但不想把一切都交给某个供应商。@tom_doerr 提到 Continuous-Claude-v3 这个围绕 handoff、recall 和提取学习构建的编程环境，而 @kevincodex 则把 memlawb 定位为零知识替代方案——服务器永远看不到明文记忆。@DerekNee 也从 组织设计角度推动了同样的需求，坚持认为记忆、审批和证明都应该属于作用域清晰的 workspace，而不是塞进一个无所不知的智能体里。机会：直接。
付费模型、付费数据和受治理花费的单一集成入口¶
信息流也指向了一个更无聊、但更紧迫的愿望：开发者希望把经济层抽象掉。@WilliamBryk 把 Exa Connect 描述成付费、可供智能体读取的数据市场；@ampersend_ai 描述了 用于付费智能的托管支付路由和预算机制；@StudentOffersHQ 则展示了 单 key 多模型端点，作为同一趋势在访问层的版本。这种需求是现实的，而不是理想化的：这 3 条帖子都在谈如何减少初始接入工作和持续的集成负担。机会：直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Anthropic Effective AI Agents guide | 架构框架 | (+) | 为单智能体、顺序、并行、分层和 evaluator-optimizer 设计提供清晰的模式分类 | 社区回复仍警告，如果一个循环就能跑通任务，很多多智能体栈其实并无必要 |
| Taste Skill | UI / 设计技能 | (+/-) | 能改善 AI 构建界面的布局、排版、动效和留白；以技能形式安装简单 | 回复质疑这种“审美”能否跨工具调用、跨不同智能体运行时保持一致 |
Hermes /learn |
技能生成 | (+) | 能把文档、SDK 和笔记变成经过测试、可复用的 SKILL.md 命令 |
没回答后续由谁来废弃或重写过时技能 |
| Continuous-Claude-v3 | 持久化编程环境 | (+/-) | 提供 YAML handoff、提取学习、109 个技能、32 个智能体，以及跨会话的上下文连续性 | 搭建很重、活动部件很多：Python、uv、Docker、PostgreSQL、hook 和智能体 |
| Library Skills | 与依赖同步的技能安装器 | (+) | 能让官方库指导与已安装包版本保持同步，并支持 Claude Code 技能路径 | 依赖库维护者真的去发布并维护这些内嵌技能 |
| memlawb | 记忆层 | (+) | 零知识存储、MCP 原生工具、自托管，以及基于密文的增量同步 | 需要用户或团队自己承担口令和存储管理责任 |
| Exa Connect | 付费数据市场 | (+/-) | 让智能体可以访问 ZoomInfo、Crunchbase、Similarweb 等专有数据源 | 早期市场活力仍取决于提供方参与度和预算纪律 |
| Ampersend + AgentCore Payments | 智能体支付 / 路由 | (+) | 单次集成、两跳结算、支出预算，以及面向付费智能的可审计支付流 | 团队仍需考虑支付策略、提供方信任和智能体商业治理 |
| Zyloo | 模型网关 | (+/-) | 提供单个 OpenAI 兼容端点，以及跨多种前沿模型的提供方级定价 | 当前证据主要来自截图和用户测试，而非深入的公开技术文档 |
整体满意度更偏向那些能让智能体行为更显式、更可复用的工具：技能、记忆层、路由层和支付控制。较弱的情绪通常出现在某个工具承诺“魔法”，却没有解决技能过时、作用域边界或限流等生命周期问题的时候。
工具组合中也出现了一个清晰的迁移模式。开发者不再让一个昂贵模型包办一切，而是越来越多地叠加多个控制面：架构指南或循环、技能系统、记忆层，以及模型或付费数据的访问层。最强的竞争动态已经不是模型对模型，而是栈对栈。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| 面向外呼销售的 Claude | @austinh___ | 面向 AE 和 SDR、连接 40+ 数据源的聊天式 GTM 助手 | 让销售团队在无需技术搭建的情况下获得智能体式外呼支持 | 专有应用、聊天工作流、40+ 数据源 | Beta | tweet |
| Taste Skill | @aiedge_ 推荐 Leonxlnx | 提升 AI 生成 UI 审美的前端技能包 | 通用 AI 界面仍然模板感强、上下文感弱 | Skills CLI、前端设计规则、配套图像生成技能 | 已发布 | tweet, site, repo |
| Continuous-Claude-v3 | @tom_doerr 推荐 Parcadei | 带有 handoff、记忆、hook、技能和专用智能体的持久化 Claude Code 环境 | 会话压缩和重复初始化会抹掉上下文、浪费 token | Python、uv、Docker、PostgreSQL、YAML handoff、109 个技能、32 个智能体 |
Beta | tweet, repo |
| Library Skills | @tiangolo | 让库可以随发布一起提供官方智能体技能，并保持同步 | 智能体容易使用过时或幻觉化的库模式 | Python/JS 包扫描、受管理符号链接、包内嵌技能 | 已发布 | tweet, site, repo |
| memlawb | @kevincodex | 面向智能体的零知识、可自托管记忆 | 团队希望获得持久记忆，但又不想把明文交给托管方 | Bun/TypeScript、MCP server、AES-256-GCM、filesystem/S3 风格后端 | Beta | tweet, repo |
| Exa Connect | @ExaAILabs / @WilliamBryk | 可供智能体查询的专有数据市场 | 仅靠公共网络搜索，无法满足许多商业工作流 | 付费数据提供方、基于 API 的访问、面向智能体的市场 | 已发布 | launch context, quoted launch |
| Ampersend | @ampersend_ai | 面向智能体的按智能计费路由与结算层 | 开发者不想为每个提供方单独搭建计费、托管和支出限制 plumbing | AgentCore Payments、x402、Coinbase CDP、Base 上的 USDC、提供方路由 | 已发布 | tweet, AWS post |
Continuous-Claude-v3、Library Skills 和 memlawb 从不同层面攻击了同一个瓶颈。一个在编程环境内部管理 handoff 和编排，一个在依赖安装时分发官方库指导，另一个则让跨会话记忆变得持久，而无需把明文访问权交给宿主。
Taste Skill 和 Hermes /learn 也指向一种可重复的构建者模式：把工作流里总是要重复教的那一部分编码下来。前者复用的是设计审美，后者则是从源材料生成、经过测试的操作技能。
Exa Connect、Ampersend 和那个外呼销售助手则展示了另一种重复模式。开发者正在把垂直领域工作流包裹上一层数据访问、模型访问和支付路径，而不是赌一个原始前沿模型本身就是产品。
6. 新动态与亮点¶
Anthropic 的架构指南成了当天的共享对象¶
@0xCodez 分享了（75 点赞、17 回复、7,086 浏览、70 收藏）Anthropic 的 《Building Effective AI Agents》，而同一天的多条其他帖子也复用了其中关于循环和架构的词汇。这一点重要，是因为讨论并不只是围绕智能体的一般性 hype，而是在收敛到一个公开、共享的结构化参考，用来说明该如何搭建它们。
Hermes /learn 把技能编写变成了摄取式工作流¶
@akshay_pachaar 展示了（36 点赞、2 回复、5,124 浏览、39 收藏），现在只要给一个文档 URL、SDK 目录、walkthrough 或普通笔记，就能在智能体真正现场执行任务之前，先生成一个经过测试的技能。这一点之所以重要，是因为它把技能从手工打包的提示词产物，转成了可生成、可验证的工作流资产。
零知识记忆从讨论点升级成了产品层能力¶
@kevincodex 发布了（27 点赞、4 回复、986 浏览）memlawb，其公开仓库把隐私主张说得非常具体：客户端加密、仅同步密文，以及用于保存 / 回忆 / 搜索的本地 MCP 工具。此前几天的信息流里已经有很多关于记忆的讨论；而这是最清晰的例子之一，显示这种担忧已经沉淀成一个边界明确的产品类别。
7. 机会在哪里¶
[+++] 技能生命周期系统 —— 第 1、2、3、4 节的证据都指向同一个缺失层：Hermes /learn、Library Skills、Dan Kornas 对发现问题的抱怨，以及 Taste Skill 跨模型漂移的疑问，都在说明同一件事。团队需要一种技能体系，既能从源材料生成，又能随着依赖变化而版本化、被快速发现，并在过时时被退役。
[+++] 具备作用域记忆和 workspace 控制面的系统 —— Continuous-Claude-v3、memlawb、Derek Nee 的 Matrix 设计，以及关于测试框架的讨论都在强化同样的需求：持久性必须能跨会话存活，但不能因此变成一个权力过大、上下文臃肿的智能体。最强的机会并不是“通用记忆”，而是“记忆 + 作用域 + 证明 + 归属 + 隐私”。
[++] 模型、数据与支付访问层 —— Exa Connect、Ampersend 和 Zyloo 都显示出人们对单一集成入口的需求，希望它能隐藏逐个提供商接入的摩擦。这个机会强度中等，因为很多团队显然现在就需要它，但这个空间大概率会很拥挤，而且基础设施属性很重。
[+] 具有硬 ROI 信号的垂直 operator 智能体 —— 外呼销售助手的 57,548 次 beta 查询和 45% 周环比增长表明，只要接上正确数据源，垂直领域智能体就能很快跑出可衡量的使用量。今天的证据比工具链主题更窄，但已经具体到值得重视。
8. 要点总结¶
- 关于智能体的讨论又往前走了一步，离提示词更远，离系统设计更近。 Akshay Pachaar 关于循环的讨论串、Chris Wolfe Research 对测试框架的定义、Derek Nee 的“公司操作系统”框架，以及 Anthropic 公开的架构指南，都把智能体描述成带有状态、证明和明确控制面的结构化系统。(source)
- 技能正在成为工作流的一等封装格式，但生命周期管理仍未解决。 Hermes
/learn、Library Skills 和 Taste Skill 都显示出强劲进展，而围绕技能过时、发现和跨模型漂移的回复，则指出了真正仍然痛的地方。(source) - 持久记忆正被当作基础设施，而不再只是“锦上添花”的提示词技巧。 Continuous-Claude-v3 和 memlawb 都把记忆视为持久系统层，而 memlawb 则通过让服务器看不到明文，把这种隐私取舍明确化了。(source)
- 商业化智能体栈越来越围绕模型之外的访问层展开。 Exa Connect 负责专有数据、Ampersend 负责支付、Zyloo 负责多模型访问，它们都指向同一个模式：真正可能赢下来的产品层，未必是底层模型本身，而是那条受治理的“智能访问路径”。(source)