Twitter AI Agent - 2026-06-25¶
1. 人们在讨论什么¶
1.1 循环工程已成为一门明确的架构学科（🡕）¶
主导性的讨论已不再只是“循环很重要”，而是转向循环本身必须包含哪些要素：触发器、独立检查器、外部状态、范围明确的工作代理、证明机制，以及终止规则。至少有四条高质量内容支撑了这一主题。
@akshay_pachaar 认为（998 个赞、44 条回复、129,289 次浏览、1,690 次收藏）指出，除非把触发器、执行者—检查者分离、磁盘持久化状态、停止条件和可观测性都纳入系统，否则人类仍然是瓶颈。他将 Graphiti 称为状态层，将 Opik 称为追踪层，这使得这条帖子不只是关于自主性的口号。
@cwolferesearch 定义（43 个赞、2 条回复、1,886 次浏览、43 次收藏）将智能体定义为运行在 agentic loop 中的 LLM，并提出四个明确的支撑框架组件：主干、指令、工具和环境，外加清晰的终止检查。配图进一步把这一说法具体化，展示了上下文管理和记忆在框架中的位置，而不是把它们当作提示词细节处理。
@0xCodez 流传（75 个赞、17 条回复、7,086 次浏览、70 次收藏）介绍了 Anthropic 的 构建高效 AI 智能体：架构模式与实现框架，概括了单智能体、顺序、并行、层级以及评估器—优化器等模式。Anthropic 的公开资源页也证实，该指南聚焦的是单智能体设计、多智能体编排和生产级案例，而不是泛泛而谈的提示词建议。
@DerekNee 提出异议（33 个赞、5 条回复、1,908 次浏览、42 次收藏）讨论了“一个拥有所有工具和文件的巨型智能体”这一思路，并提出一个 Matrix 式的“公司操作系统”：工作区大脑、部门负责人、范围明确的工作代理，以及证明循环。这是最清晰的信号之一，表明争论已经从“我该不该用智能体？”转向“如何在不失去问责的前提下组织自治？”
讨论洞察： 最有分量的回复都在谈失败模式。对 Akshay 线程的一条回复称，真正需要保持不变的是：目标、状态、证据和退出标准必须保存在模型之外；而对 Derek Nee 的一条回复则指出，过长的工具列表会让模型在循环中途开始漏掉调用。
与前一天对比： 6 月 24 日已经大量讨论了循环、技能和状态。到 6 月 25 日，这一讨论进一步推进到了明确的支撑框架组件、以证明为主导的组织设计，以及公开发布的架构指南。
1.2 技能与记忆正成为可复用的运行层，而不再只是提示词碎片（🡕）¶
第二个主题是封装。人们分享的不再只是提示词，而是把工作流、库知识、UI 品味和记忆封装成可安装、可跨会话延续的构件。至少有五条高质量内容支撑了这一主题。
@akshay_pachaar 解释（36 个赞、2 条回复、5,124 次浏览、39 次收藏）介绍了 Hermes Agent 的新 /learn 流程：把文档 URL、SDK 目录、操作演示或笔记交给智能体，它就会生成经过测试的 SKILL.md，并将其变成可通过斜杠命令调用的技能。他在线程中强调的关键区别在于，这把技能创建前移到了工作流起点，而不是等智能体反复失败后才“学会”这一经验。
@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 交接、由守护进程提取的经验、109 项技能、32 个智能体和 30 个钩子。这套栈比简单的提示词文件重得多，但它也表明，构建者正把上下文连续性尽可能转化为系统行为。
@kevincodex 发布（27 个赞、4 条回复、986 次浏览）介绍了 memlawb，这是一层面向智能体的零知识记忆层。其公开仓库称，记忆会在客户端使用 AES-256-GCM 加密，只以密文形式同步，并通过 MCP 工具 memory_save、memory_recall 和 memory_search 提供访问。
讨论洞察： 最有价值的质疑集中在维护，而不是创建。一条回复 /learn 线程的评论问道：当工具或约束发生变化时，谁来标记某项技能已经过时？而 Taste Skill 的回复则质疑，在长时间、频繁使用工具的运行过程中，风格是否还能保持稳定。
与前一天对比： 6 月 24 日强调了技能作为可复用工作流包的价值。到 6 月 25 日，讨论进一步转向从源材料生成技能、与依赖同步的库级指导，以及作为专用基础设施的隐私保护记忆。
1.3 智能体业务正围绕路由、付费数据和受治理访问搭建起来（🡕）¶
第三个主题是通过基础设施实现商业化。商业侧最强的帖子都在讨论，如何让智能体接入正确的数据、正确的模型和正确的支付通道，而不必让开发者每次都从头重建这些层。至少有四条保留内容支撑了这一主题。
@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 帖子 为 AI 智能体构建按智能付费模式 证实了这种双跳设计：智能体通过 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 技能确实有用，但找到合适技能仍然很混乱，因此他强调的是一份精选列表，而不是又一个单独技能。@aiedge_ 曝光 介绍了一项引发强烈兴趣的设计技能，但回复质疑风格规则能否在工具调用过程中保持，或能否跨模型迁移。当前的应对方式是策展、版本管理，以及像 Library Skills 这样由官方库支持的技能，但治理问题仍未解决。
数据、模型和支付这几层基础设施仍然吞噬过多工程时间¶
严重程度：高。@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 介绍了一个围绕交接、召回和经验提取构建的编码环境，而 @kevincodex 将其定位为 memlawb 则提供了零知识替代方案，让服务器永远看不到明文记忆。@DerekNee 推动 也从组织设计的角度提出了同样的需求：记忆、审批和证明应当位于范围明确的工作区之内，而不是塞进一个全知全能的智能体里。机会：直接。
为付费模型、付费数据和受治理支出提供单一集成点¶
信息流也指向了一个更朴素但更迫切的愿望：构建者希望把经济层抽象掉。@WilliamBryk 描述 将 Exa Connect 视为付费、面向智能体可读的数据市场，@ampersend_ai 描述 指向面向付费情报的托管支付路由和预算控制，而 @StudentOffersHQ 展示 则代表了同一趋势在访问层的一键式多模型端点形态。这种需求是务实的而非理想化的：这三条帖子都在讨论如何减少初始配置工作和持续集成开销。机会：直接。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Anthropic Effective AI Agents guide | 架构框架 | (+) | 为单智能体、顺序、并行、层级和评估器—优化器设计提供清晰的模式分类 | 社区回复仍提醒，如果一个循环就能完成任务，许多多智能体技术栈其实没有必要 |
| Taste Skill | UI / 设计技能 | (+/-) | 改善 AI 构建界面的布局、字体、动效和间距；基于技能的安装方式简单易用 | 回复质疑这种“品味”能否跨工具调用过程和不同智能体运行时保持一致 |
Hermes /learn |
技能生成 | (+) | 将文档、SDK 和笔记转化为经过测试、可复用的 SKILL.md 命令 |
没有回答后续由谁来废弃或重写过时技能 |
| Continuous-Claude-v3 | 持久化编码环境 | (+/-) | 提供 YAML 交接、经验提取、109 项技能、32 个智能体，以及跨会话的上下文连续性 | 配置较重、活动部件很多：Python、uv、Docker、PostgreSQL、钩子和智能体 |
| Library Skills | 与依赖同步的技能安装器 | (+) | 让官方库指导与已安装包版本保持同步，并支持 Claude Code 技能路径 | 依赖库维护者确实发布并维护内嵌技能 |
| memlawb | 记忆层 | (+) | 零知识存储、MCP 原生工具、自托管，以及基于密文的增量同步 | 将口令和存储管理责任转移给用户或团队 |
| Exa Connect | 付费数据市场 | (+/-) | 让智能体访问 ZoomInfo、Crunchbase 和 Similarweb 等专有数据源 | 早期市场动态仍取决于提供方参与度和预算纪律 |
| Ampersend + AgentCore Payments | 智能体支付 / 路由 | (+) | 单一集成、双跳结算、支出预算，以及面向付费情报的可审计支付流 | 团队仍需考虑支付策略、提供方信任和智能体商业治理 |
| Zyloo | 模型网关 | (+/-) | 一个 OpenAI 兼容端点，以及覆盖多个前沿模型的提供方级定价 | 当天的证据主要来自截图和用户测试，而不是深入的公开技术文档 |
总体满意度更偏向那些让智能体行为更明确、更可复用的工具：技能、记忆层、路由层和支付控制。评价较弱时，往往是因为某个工具承诺了“魔法”，却没有解决技能过时、作用域边界或速率限制等生命周期问题。
工具组合中还出现了清晰的迁移模式。开发者不再寄望于一个昂贵模型包办一切，而是越来越多地叠加多个控制面：架构指南或循环、技能系统、记忆层，以及模型或付费数据的访问层。最强的竞争动态已不再是模型对模型，而是技术栈对技术栈。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Claude for outbound sellers | @austinh___ | 面向 AE 和 SDR、覆盖 40+ 个数据源的聊天式 GTM 助手 | 为销售团队提供智能体化的外呼支持，无需技术配置 | 专有应用、聊天工作流、40+ 个数据源 | Beta | 推文 |
| Taste Skill | @aiedge_ 介绍 Leonxlnx | 用于提升 AI 生成 UI 品味的前端技能包 | 通用 AI 界面依然模板化严重、上下文感不足 | Skills CLI、前端设计规则、图像生成配套技能 | 已发布 | 推文, 网站, 代码库 |
| Continuous-Claude-v3 | @tom_doerr 介绍 Parcadei | 持久化的 Claude Code 环境，带有交接、记忆、钩子、技能和专用智能体 | 会话压缩和重复配置会抹去上下文、浪费 token | Python、uv、Docker、PostgreSQL、YAML 交接、109 项技能、32 个智能体 |
Beta | 推文, 代码库 |
| Library Skills | @tiangolo | 让库随包发布可与版本同步的官方智能体技能 | 智能体经常使用过时或幻觉化的库模式 | Python/JS 包扫描、受管控的符号链接、内嵌包技能 | 已发布 | 推文, 网站, 代码库 |
| memlawb | @kevincodex | 面向智能体的零知识、可自托管记忆 | 团队想要持久记忆，又不想把明文交给托管方 | Bun/TypeScript、MCP 服务器、AES-256-GCM、文件系统/S3 风格后端 | Beta | 推文, 代码库 |
| Exa Connect | @ExaAILabs / @WilliamBryk | 可供智能体查询的专有数据市场 | 对许多商业工作流而言，公开网络搜索并不够用 | 付费数据提供方、基于 API 的访问、面向智能体的市场 | 已发布 | 发布背景, 引用的发布内容 |
| Ampersend | @ampersend_ai | 面向智能体的按情报付费路由与结算层 | 构建者不想为每个提供方分别搭建定制计费、托管和支出限额基础设施 | AgentCore Payments、x402、Coinbase CDP、Base 上的 USDC、提供方路由 | 已发布 | 推文, AWS 帖子 |
Continuous-Claude-v3、Library Skills 和 memlawb 从不同层面瞄准了同一个瓶颈。一个在编码环境内管理交接和编排，一个在依赖安装时分发官方库指导，一个则让跨会话记忆具备持久性，同时不让托管方看到明文。
Taste Skill 和 Hermes /learn 也指向了一种可重复的构建模式：把工作流中那些不断被重新教给模型的部分固化下来。前者把设计品味做成可复用资产，后者则把从源材料生成并经测试的操作技能做成资产。
Exa Connect、Ampersend 和这款外呼销售助手则展示了另一种反复出现的模式。构建者正在围绕垂直工作流，封装通向正确数据、正确模型和正确支付路径的访问层，而不是押注于仅靠原始前沿模型就能成为产品。
6. 新内容与值得关注的动态¶
Anthropic 的架构指南成了当天的共同参照物¶
@0xCodez 分享（75 个赞、17 条回复、7,086 次浏览、70 次收藏）介绍了 Anthropic 的 构建高效 AI 智能体，而同一天的多条其他帖子也复用了其中关于循环和架构的词汇。这很重要，因为讨论不再只是围绕“智能体”这一概念本身的热炒，而是在收敛到一个关于如何组织智能体的共同公开参考。
Hermes /learn 把技能编写变成了摄取式工作流¶
@akshay_pachaar 展示（36 个赞、2 条回复、5,124 次浏览、39 次收藏）指出，如今可以在智能体真正执行任务之前，就把文档 URL、SDK 目录、操作演示或普通笔记转化为经过测试的技能。这一点值得关注，因为它把技能从手工制作的提示词包，转变成了可生成、可验证的工作流资产。
零知识记忆从讨论点升级为产品表面¶
@kevincodex 发布（27 个赞、4 条回复、986 次浏览）介绍了 memlawb，其公开仓库把隐私主张具体化为：客户端加密、仅同步密文，以及用于保存、召回和搜索的本地 MCP 工具。此前几天的信息流里已经有不少关于记忆的讨论；这是其中最清晰的案例之一，表明这一关切正在凝结为一个具有明确技术边界的产品类别。
7. 机会在哪里¶
[+++] 技能生命周期系统 —— 第 1、2、3、4 节的证据都指向同一个缺失层：Hermes /learn、Library Skills、Dan Kornas 关于发现困难的抱怨，以及 Taste Skill 的跨模型漂移问题，都说明团队需要这样一层系统：能够从源材料生成技能，随着依赖变化进行版本管理，被快速发现，并在过时时及时退役。
[+++] 有范围的记忆与工作区控制平面 —— Continuous-Claude-v3、memlawb、Derek Nee 的 Matrix 设计，以及对支撑框架的讨论，都在强化同一个需求：持久性必须能跨会话保留，但又不能演变成一个权力过大、上下文臃肿的单一智能体。最强的机会不是泛泛的记忆，而是记忆与范围、证明、所有权和隐私的结合。
[++] 模型、数据与支付访问层 —— Exa Connect、Ampersend 和 Zyloo 都显示出对单一集成点的需求，以隐藏逐个对接提供方的摩擦。这个机会是中等强度，因为许多团队显然现在就需要它，但这个领域也很可能迅速变得拥挤且基础设施负担沉重。
[+] 带有明确 ROI 信号的垂直运营型智能体 —— 这款外呼销售助手的 57,548 次 beta 查询和 45% 的周环比增长表明，只要配上合适的数据源，垂直领域智能体就能快速产生可量化的使用量。当天关于这一点的证据不如工具主题那么广，但已经足够具体，值得重视。
8. 要点¶
- 关于智能体的讨论又进一步远离提示词，转向系统设计。 Akshay Pachaar 的循环线程、Chris Wolfe Research 对支撑框架的定义、Derek Nee 的公司操作系统视角，以及 Anthropic 的公开架构指南，都把智能体描述为具备状态、证明和明确控制面的结构化系统。（来源）
- 技能正成为工作流的一等封装格式，但生命周期管理仍未解决。 Hermes
/learn、Library Skills 和 Taste Skill 都显示出明显进展，而围绕技能过时、发现困难和跨模型漂移的回复，则揭示了仍然棘手的痛点。（来源） - 持久化记忆正被当作基础设施，而不是可有可无的提示词技巧。 Continuous-Claude-v3 和 memlawb 都把记忆视为持久的系统层，而 memlawb 则通过让服务器看不到明文，把其中的隐私权衡说得非常具体。（来源）
- 商业智能体技术栈越来越围绕模型之外的访问层展开。 Exa Connect 对应专有数据，Ampersend 对应支付，Zyloo 对应多模型访问，它们共同指向同一种模式：最终胜出的产品表面，可能是通向智能的受治理路径，而不只是底层模型本身。（来源）