Twitter AI Agent - 2026-06-24¶
1. 人们在讨论什么¶
1.1 持久化的队友型 Agent 正从演示走向日常工作界面（🡕）¶
最强的一条主线，已经不再是单一聊天窗口，而是 Agent 正在成为常驻型协作者：它们存在于共享工作界面中，持续保留上下文，并且在人类离开后仍会继续运行。至少有四条保留内容支撑了这一主题。
@karpathy 认为（7,076 个赞、389 条回复、917,172 次浏览、3,866 次收藏）称，Claude 的 LLM 界面已进入“第三次重大重构”：从网站，到桌面应用，再到一个具备全组织工具与上下文、可独立存在、持久运行、异步工作的实体。引用的 Claude Tag 发布 让这一说法更具体：Claude 以权限受限的队友身份加入 Slack，记住频道上下文，可异步工作，并提供支出限额和审计日志。
@AlexFinn 报道（248 个赞、17 条回复、18,688 次浏览、223 次收藏）称，Hermes 现在默认采用后台 Agent，新增技能中心，开放实时子 Agent 面板，并允许用户通过 iMessage 或 Telegram 向系统发消息。真正值得注意的不是某个单独功能，而是其背后的产品假设：即使用户切换设备或上下文，Agent 也应继续运行。
@cryptoleek 标记了（77 次浏览）称，PI WEB 可让 Pi Coding Agent 会话在浏览器关闭和服务器重启后仍然存活。公开仓库说明，浏览器 UI 前端连接的是独立的会话守护进程和 Pi SDK，因此长时运行的工作区与会话不会随着 UI 重启而消失，也不会因标签页关闭而终止。
讨论洞察： 最有价值的反驳在于，这究竟是真创新，还是只是包装得更好。Karpathy 的帖子下面，回复立刻追问这和早期“@ 一个 Agent”的方案有何不同；给出的答案集中在企业级部署、受限工具、记忆能力和多人协作连续性，而不是基础的聊天调用。
与前一天的对比： 6 月 22 日已经出现了团队工作区、记忆层和统一 Agent API；到 6 月 24 日，这一趋势又往前推进了一步，变成共享、常在线、行为更像同事而非标签页的团队工作界面。
1.2 Harness 与循环工程持续取代提示词技巧（🡕）¶
第二个主题是，当天真正重要的操作能力已不再是“把提示词写得更好”，而是设计循环、把状态外置、将工作流封装为技能，并加入能够跨多次运行持续生效的护栏。最有力的证据既来自高互动的解释型长帖，也来自互动不高但极其具体的实践清单。
@akshay_pachaar 写道（797 个赞、37 条回复、103,374 次浏览、1,337 次收藏）称，循环工程之所以重要，是因为否则人类仍然要在循环里充当调度者和检查者。他的帖子直接点出了缺失环节：触发器、maker/checker 分离、磁盘持久化状态、明确的停止条件、通过 Graphiti 实现的时间型记忆，以及通过 Opik 实现的 harness 可观测性。
@swadeshkumar_ 认为（6 个赞、85 次浏览）称，Claude Code 在仓库本身按 Agent 方式组织时效果最好：简短的 CLAUDE.md 文件、可复用的 .claude/skills/、用于强制检查的 hooks，以及 Agent 能自行导航的文档，而不是把所有东西都塞进提示词。这是一条小帖，但它把当天关于循环的抽象讨论，落成了具体的仓库布局。
@charliejhills 汇编了（24 个赞、7 条回复、3,161 次浏览）分享了一份包含 17 个链接的 Claude Skills 资源包，其中包括 Anthropic 的 agent skills 最佳实践。与此同时，agent-skills 仓库 将 skills 描述为生产级工作流封装包，通过斜杠命令覆盖 spec、plan、build、test、review 和 ship 等环节。
讨论洞察： 反复出现的关键细节是，状态必须存放在模型之外。Akshay 帖子下的一条回复指出，真正重要的不是一个长时运行的 Agent 还是多个 Agent，而是把目标、任务、状态、证据和退出标准保存在上下文窗口之外。
与前一天的对比： 6 月 22 日的重点仍然是编排产品和模式目录；到 6 月 24 日，重心已转向模型周边的工程层：循环、文件、hooks 和 skills。
1.3 记忆、技能审查与最小权限控制成为显式基础设施（🡕）¶
信息流还把一些过去较为模糊的 Agent 问题，明确塑造成具体基础设施类别：可模块化评估的记忆系统、针对第三方技能的安装前扫描，以及根据具体任务推导权限范围、而非让助手长期持有过高权限的授权模型。
@dair_ai 总结了（128 个赞、14 条回复、7,612 次浏览、145 次收藏）在讨论一篇长期记忆论文时表示，Agent 记忆如今已成为一个数据管理层，涵盖存储、检索、更新、整合和生命周期治理。这一观点之所以重要，在于它拒绝把端到端任务成功率当作唯一指标，而是推动对记忆进行模块级评估。
@KentonVarda 认为（99 个赞、13 条回复、6,818 次浏览、78 次收藏）称，为每个 Agent 明确逐一配置权限，是错误的安全模型，因为它无法扩展。他提出的替代方案是基于能力的安全：每个新任务都获得自己的 Agent，其权限由人类提供的具体资源推导得出，而且 Agent 的全部权限始终只是人类权限的子集。
@JafarNajafov 强调了（9 个赞、718 次浏览）提到一组快速升温的仓库：headroom 用于减少 60-95% 的 token，agent-skills 用于封装工程工作流，SkillSpector 用于安装前技能扫描。SkillSpector 的公开 README 称，被扫描技能中有 26.1% 含漏洞，5.2% 显示出可能的恶意意图，这让技能安装看起来更像供应链安全问题，而不是随手分享提示词。
@NostaIgicGareth 指向了（494 次浏览）提到 agentmemory，其公开仓库将自己定位为 Claude Code、GitHub Copilot CLI、Cursor、Gemini CLI、Codex CLI、Hermes、OpenClaw、pi 和 MCP 客户端的持久化记忆层。README 上的徽章自称检索 R@5 达到 95.2%，token 减少 92%，这与当天“让记忆更便宜也更耐久”的整体趋势一致。
讨论洞察： 围绕记忆和授权两类帖子的回复，最终都汇聚到同一原则：Agent 不应因为“聪明”就被信任；只有当记忆、权限和验证都被明确化时，它们才值得信任。
与前一天的对比： 6 月 22 日已经把记忆与治理作为相邻议题浮现出来；到 6 月 24 日，这些议题进一步具象化为模块级记忆框架、安装时扫描器，以及明确的最小权限论证。
1.4 Agent 产品持续扩展到销售、云运维、支付与研究（🡕）¶
最后一个主要主题是广度。当天的构建者不再只发布编程助手，而是把同样的 Agent 模式应用到外呼销售、云基础设施、机器支付和打包式研究服务上。
@austinh___ 宣布（219 个赞、56 条回复、240,357 次浏览、144 次收藏）介绍了一款面向外呼销售的聊天产品，可接入 40+ 数据源。帖中最有力的证据不是概念，而是运营数据：测试版上线最初几周就完成了 57,548 次查询，并实现了 45% 的周环比增长。
@mvcinvesting 报道（467 个赞、21 条回复、30,593 次浏览、33 次收藏）称，Nebius AI Cloud 3.6 新增了 Echo——一个用于基础设施控制的自然语言 Agent——同时还加入 KMS、客户管理加密密钥、Workload Identity Federation 以及大规模存储升级。关于 Nebius AI Cloud 3.6 的公开发布报道也采用了同样的表述框架。
@ampersend_ai 解释了（7 个赞、386 次浏览、3 次收藏）介绍了一个构建在 Amazon Bedrock AgentCore Payments 之上的“按智能付费”路由层。配套的 AWS 文章 描述了一种双跳支付流程：Agent 向 Ampersend 付款，再由 Ampersend 与上游模型提供商结算；x402、预算和可审计性都由底层处理。
@Capafyai 推出了（125 次浏览）介绍了 Deep Research Pro：一种可销售的技能型 Agent，能把问题转化为带引用支撑的报告。公开的 Capafy skills 仓库 和 deep-research-pro 仓库 都明确表明了这一模式：研究工作流正被封装为闭源或可复用服务，而不再只是私人提示词。
讨论洞察： 这些产品的有趣共性在于，它们都在模型之外包了一层额外基础设施：销售的数据连接器、云控制的治理机制、自主调用的托管支付，以及研究技能的市场/IP 轨道。
与前一天的对比： 6 月 22 日强调的是编排系统和团队工作区；到 6 月 24 日，则可以看到同一套设计逻辑已开始在相邻业务职能中商业化。
2. 什么让人沮丧¶
如果团队不在模型之外构建记忆，上下文仍然会消失¶
严重程度：高。@akshay_pachaar 表示（797 个赞、37 条回复、103,374 次浏览、1,337 次收藏）称，状态必须落盘，而不能只放在上下文里，因为模型会在多次运行之间遗忘。@dair_ai 将其定义为（128 个赞、14 条回复、7,612 次浏览、145 次收藏）则从更结构性的角度指出同一问题：记忆现在需要存储、检索、更新、整合和治理，但大多数团队仍把它当黑箱来评估。@NostaIgicGareth 披露了（494 次浏览）提到 agentmemory，正是因为人们已经厌倦了每次会话都要重新解释代码库。现有应对模式已经很清楚：持久化记忆层、上下文压缩，以及文件持久化状态。这个方向值得投入，因为多条互不相关的帖子都汇聚到了同一个痛点。
当 Agent 一开始就权限过大时，授权与安全都会失效¶
严重程度：高。@KentonVarda 认为（99 个赞、13 条回复、6,818 次浏览、78 次收藏）称，要求预先配置每个 Agent 的权限既无法扩展，也会鼓励默认权限过大的助手。对 @karpathy 补充说（7,076 个赞、389 条回复、917,172 次浏览、3,866 次收藏）的一条回复，则给出了同一担忧的操作层版本：如果 Claude 是一名队友，它也需要 IAM、审计轨迹，以及在它做出昂贵操作之前能够干净停下它的方式。由 @JafarNajafov（9 个赞、718 次浏览）带出的 SkillSpector 仓库，又在安装阶段补充了另一条安全抱怨：其声称被扫描技能中有 26.1% 含漏洞，5.2% 显示出可能的恶意意图。当天的变通办法，是加入扫描器、范围受限的能力和明确源于人类的授权，而不是信任宽泛的默认访问权限。
生产级 Agent 在资金、云控制与可观测性方面仍需大量配套设施¶
严重程度：高。@ampersend_ai 介绍了（7 个赞、386 次浏览、3 次收藏）描绘了这样一种局面：如果没有现成基础设施，每个付费模型或数据端点都会迫使开发者重复搭建钱包托管、x402 支持、支出限额和计费集成。@mvcinvesting 展示了（467 个赞、21 条回复、30,593 次浏览、33 次收藏）称，如今连云控制也会随产品一起提供 KMS、Workload Identity Federation 和预算，因为光有自然语言控制还远远不够。@akshay_pachaar 还表示 指出，可观测性不仅要确认某一次运行通过，还必须在模型或提示词变化后捕捉 harness 漂移。这个方向看起来值得投入，因为同一天关于支付、云控制和循环管理的帖子，都暴露出相同的“额外配套层”问题。
3. 人们希望存在什么¶
能跨交接持续存在的共享 Agent 身份¶
最明确的现实需求，是让 Agent 像耐久队友，而不是一次性会话助手。@karpathy 介绍了（7,076 个赞、389 条回复、917,172 次浏览、3,866 次收藏）把理想状态描述为一个具备全组织工具和记忆、可异步运行的实体，而 Anthropic 的 Claude Tag 公告 则补充了频道范围控制、环境式更新和支出控制。@cryptoleek 展示了（77 次浏览）又从编程侧表达了同样的需求：PI WEB 中，会话可跨浏览器关闭和设备切换继续存在。机会：直接。
原生于仓库的工作流封装，而不是反复盯着提示词¶
人们也希望用可复用的工作流结构来压过提示词漂移。@swadeshkumar_ 认为（6 个赞、85 次浏览）主张使用简短的 CLAUDE.md 文件、本地上下文文件、hooks 和 skills；而 @charliejhills 收集了（24 个赞、7 条回复、3,161 次浏览）则给出了恰好适配这一工作流的文档与示例。agent-skills 仓库 也用将 skills 映射到 spec、plan、build、test、review 和 ship 各阶段的方式，明确表达了同样的需求。机会：直接。
在不让 token 成本失控的前提下保留有效信息的记忆与压缩层¶
第二个强需求，是用系统保住以往工作的有用部分，同时压低不断膨胀的上下文成本。@dair_ai 将其定义为 将记忆视为受治理的数据系统，@NostaIgicGareth 指向了 通过 agentmemory 提供持久化记忆，而 @JafarNajafov 披露了 headroom 则作为压缩层，声称可减少 60-95% 的 token。这个需求很现实，因为这些产品卖点针对的是当前会话限制，而不是抽象研究。机会：直接。
围绕自主行动的支付、权限与信任托管基础设施¶
信息流还暗示，人们需要一种像 Web 应用中的认证或计费那样平稳可靠的 Agent 基础设施。@ampersend_ai 认为（7 个赞、386 次浏览、3 次收藏）称，开发者不应在上线 Agent 逻辑前先自行搭建钱包托管和支出控制；而 @KentonVarda 认为 则主张使用按任务收敛、基于能力的授权，而不是宽泛的长期权限。@JafarNajafov 补充说 也通过暴露 SkillSpector，指出了同一需求在安装阶段的版本。机会：直接。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Tag | 团队 Agent 工作界面 | (+) | 共享的 Slack 原生上下文、异步工作、按频道限定的记忆、管理员控制 | 仍是测试产品，而且仍让人质疑其相较现有可标记 Agent 到底有多少真正新意 |
| Hermes Agent | 个人 Agent 运行时 | (+/-) | 后台 Agent、多配置文件工作流、技能中心、移动消息入口 | 回复里仍在追问部署摩擦、VPS 需求以及不同渠道间的体验落差 |
| Graphiti | 记忆图谱 | (+) | 时间上下文图、来源追踪、混合检索、持续演化的事实 | 又增加了一层需要运维的系统 |
| Opik | 可观测性/评测 | (+) | 轨迹采集、评估、提示词和工具优化、生产监控 | 只有团队为 harness 加入埋点并持续审查轨迹时才真正有用 |
| agentmemory | 持久化记忆层 | (+) | 跨客户端记忆、压缩、MCP 支持、基于文件的回忆能力 | 开源势头很强，但广泛的生产级证据仍然有限 |
| headroom | 上下文压缩 | (+) | 声称可减少 60-95% token，支持 library/proxy/MCP 模式，并提供跨 Agent 记忆选项 | 压缩又增加了一层团队必须信任并调优的预处理层 |
| agent-skills | 工作流封装 | (+) | 覆盖开发生命周期的 skills、斜杠命令、可复用的质量门禁 | 赛道拥挤，而且质量仍取决于 skill 作者 |
| SkillSpector | 技能安全扫描器 | (+) | 安装前扫描、覆盖 17 个类别中的 68 种模式、支持 SARIF/JSON 输出 | 重点是安装时审查；运行时滥用仍需其他控制手段 |
| Nebius Echo / AI Cloud 3.6 | 云运维 | (+/-) | 自然语言基础设施控制，以及 KMS、CMEK、WIF、存储和搜索升级 | 能力越强，接触生产环境前所需治理负担也越大 |
| PI WEB | Agent 控制平面 | (+) | 持久会话、分进程守护、多设备监管、worktree 支持 | 偏 Pi 生态，且仍主要围绕单一 Agent 体系 |
| Deep Research Pro / Capafy | 研究技能 + 市场 | (+/-) | 带引用报告、多源抓取、可变现的技能分发、IP 保护 | 市场质量与可重复性仍有待验证 |
| Ampersend + AgentCore Payments | Agent 支付 | (+) | 双跳“按智能付费”流程、预算、x402、统一提供商接入 | 依赖许多团队尚未具备的支付通道与治理层 |
总体满意度更偏向那些能让 Agent 更可检查的工具：记忆层、skills、扫描器、轨迹以及受限控制平面。负面情绪则更多出现在那些要求用户信任大范围自治、却没有配套强护栏的产品上。
最清晰的应对模式，是把关键状态和策略移出模型。团队正在把记忆存到磁盘或图谱里，在上下文送入模型前先做压缩，把可重复工作封装成 skills，并在 Agent 接触真实系统前加入扫描器或支出控制。
工具组合里也出现了迁移压力。与其依赖一个高价助手包办一切，信息流反复指向分层堆栈：像 Claude Tag 这样的团队协作界面，像 agentmemory 或 Graphiti 这样的记忆层，像 agent-skills 这样的工作流层，以及像 SkillSpector 或 AgentCore Payments 这样的安全层。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Claude Tag | @claudeai / @karpathy | 共享的 Slack 原生 Claude 队友，具备频道范围控制、工具与异步任务 | 团队需要持久化、多人协作的 Agent 工作，而不是彼此隔离的聊天 | Slack、组织级工具、频道记忆、管理员控制 | 测试版 | 推文, 公告 |
| Claude for outbound sellers | @austinh___ | 通过聊天连接 40+ 数据源的 GTM 助手 | 销售人员希望获得 Agent 式外呼帮助，而无需技术配置 | 专有应用、40+ 数据源 | 测试版 | 推文 |
| agentmemory | @NostaIgicGareth / @ghumare64 | 面向多客户端编程 Agent 的持久化记忆 | 每次会话都重新解释代码库，会浪费 token 和注意力 | iii engine、MCP、hooks、多客户端集成 | 已发布 | 推文, 仓库 |
| PI WEB | @cryptoleek / jmfederico | 面向长时运行 Pi Coding Agent 会话的浏览器控制平面 | 会话通常会随终端、浏览器标签页或设备交接而中断 | Fastify Web/API 进程、会话守护进程、Pi SDK、git worktrees | 测试版 | 推文, 仓库 |
| SkillSpector | @JafarNajafov 发现并转发 NVIDIA | 用于安装前扫描 AI Agent skills 的工具 | 团队需要审查第三方 skills 中的漏洞和恶意模式 | Python、OSV.dev、SARIF/JSON 输出、可选 LLM 分析 | 已发布 | 推文, 仓库 |
| Deep Research Pro on Capafy | @Capafyai | 将问题转化为带引用报告、并可作为服务出售的研究技能 | 通用助手往往止步于浅层摘要，而创作者希望把更强的工作流变现 | 技能型 Agent、多源搜索/抓取、Capafy marketplace | 测试版 | 推文, Capafy skills, deep-research-pro |
| Ampersend | @ampersend_ai | 位于 Agent 与模型提供商之间的“按智能付费”路由层 | Agent 构建者不想为每家提供商都重复实现钱包托管、预算和支付编排 | Amazon Bedrock AgentCore Payments、x402、Base 上的 USDC、提供商路由 | 已发布 | 推文, AWS 文章 |
Claude Tag 是当天最清晰的信号，说明 Agent 产品正在从个人生产力工具走向共享的组织工作流。关键点不只是“Slack 里的 Claude”，而是其受限身份、共享可见性、异步跟进，以及 Anthropic 所称这种模式已驱动其产品团队大部分代码产出。
agentmemory 和 PI WEB 从不同侧面攻击同一个“持久工作”问题。agentmemory 试图在多个编程客户端之间保留正确上下文，而 PI WEB 则让执行环境和会话守护进程持续存活，从而使工作本身能超越前端会话。
SkillSpector、Deep Research Pro 和 Ampersend 指向三种相邻的构建模式：一种是把专业能力封装成可复用技能，一种是通过 IP 保护把该技能作为服务出售，另一种则补上计费和预算层，让自主 Agent 能在无需每次手搓支付管线的情况下购买智能。
6. 新的和值得注意的内容¶
Claude Tag 让“Agent 作为同事”的界面变得具体¶
@karpathy 转向了（7,076 个赞、389 条回复、917,172 次浏览、3,866 次收藏）把一次产品发布变成了当天最具代表性的叙事转向：Agent 是一个独立、持久、异步的队友。配套的 Anthropic 公告 则补上了使这一说法不止于营销的公开细节：按频道限定的身份、共享可见性、环境式跟进、支出限额和日志。
安装时技能扫描成为一个清晰可见的新类别¶
@JafarNajafov 披露了（9 个赞、718 次浏览）提到 SkillSpector，而该仓库声称被扫描技能中有 26.1% 含漏洞、5.2% 显示出可能的恶意意图，这给 Agent 工具生态提供了一个具体的供应链统计数据。它之所以值得关注，是因为讨论正在从“分享你的提示词包”转向“先扫描，再安装”。
AWS 背书的 Agent 支付从概念走向实现细节¶
@ampersend_ai 展示了（7 个赞、386 次浏览、3 次收藏）称，“按智能付费”基础设施已经具体到足以进入 AWS 案例研究。配套的 AWS 说明文章 详细列出了 payment manager、双跳路由流程、预算和 x402 结算路径，具体到足以把 Agent 商业视为真实基础设施，而不只是一个与加密相邻的概念。
7. 机会在哪里¶
[+++] 持久化 Agent 控制平面 —— 第 1.1 节、第 2 节和第 5 节的证据都指向同一需求：Claude Tag、Hermes 后台 Agent、PI WEB 和 agentmemory，都在指向能够跨上下文丢失和设备变更继续维持会话、记忆与交接的能力。
[+++] 授权、扫描与支出治理层 —— Kenton Varda 关于最小权限的论证、SkillSpector 的漏洞声明、Nebius 的治理升级，以及 Ampersend 的支付预算，都指向同一块缺失堆栈：如何可信地控制 Agent 可以访问、购买和执行什么。
[++] 面向编程 Agent 的工作流封装 —— 当天关于 skills 的帖子、仓库结构建议以及快速上升的仓库，都显示出对可复用工程工作流的需求，以减少对提示词的反复盯防。这个赛道已经开始拥挤，但需求明确且就在当下。
[+] 拥有真实运营数据的垂直 Agent 应用 —— 外呼销售产品报告的 57,548 次测试版查询和 45% 周增长，说明建立在丰富数据连接器之上的领域专用 Agent 仍有空间。机会正在浮现，但当天支持这一点的产品数量仍少于基础设施主题。
8. 要点¶
- 重心已从孤立聊天会话转向持久化、共享式 Agent 工作。 Karpathy 的框架，加上 Anthropic 公开披露的 Claude Tag 细节，让这一转变变得明确。（来源）
- 循环工程如今关心的是外部状态、检查器和轨迹，而不只是更好的指令。 Akshay Pachaar 的帖子把这一工作流与 Graphiti 的记忆能力、Opik 的可观测性联系起来，而实践者帖子则把它落实为仓库结构与 skills。（来源）
- 记忆、权限和技能安全正在成为一等基础设施类别。 围绕记忆论文的帖子、基于能力的授权论证、agentmemory 仓库，以及 SkillSpector 的扫描声明，都在强化同一种模式。（来源）
- Agent 商业化正从编程扩展到云运维、支付、研究和销售。 Nebius、Ampersend、Capafy 和外呼销售产品，都展示了围绕模型叠加基础设施的具体业务界面。（来源）