跳转至

Twitter AI Agent - 2026-06-24

1. 人们在讨论什么

1.1 持久化的同事型智能体正从 demo 走向日常工作界面(🡕)

最强的一波讨论,已经不再围绕单一聊天窗口,而是围绕“智能体作为持久同事”:它们存在于共享工作界面中,保留上下文,并在人类离开后继续运行。至少有 4 个保留条目支撑了这一主题。

@karpathy 认为(7,076 点赞、389 回复、917,172 浏览、3,866 收藏),Claude 已进入 LLM UI 的“第三次重大重构”:从网站,到桌面应用,再到一个自包含、持久化、异步运行、拥有组织级工具和上下文的实体。被引用的 Claude Tag launch 把这个说法落到了实处:Claude 以受限范围的队友身份加入 Slack,记住频道上下文,可以异步工作,并带有支出上限和审计日志。

@AlexFinn Hermes 现在默认启用后台智能体,加入 skills hub、实时 subagent 面板,并允许用户通过 iMessage 或 Telegram 与系统通信(248 点赞、17 回复、18,688 浏览、223 收藏)。值得注意的不是某一个单独功能,而是背后的产品假设:即使用户切换设备或上下文,智能体也应继续运行。

@cryptoleek 指出(77 浏览),PI WEB 能在浏览器关闭和服务器重启后继续保活 Pi Coding Agent 会话。公开仓库显示,浏览器 UI 位于独立的会话守护进程和 Pi SDK 之前,因此长时间运行的工作区和会话不会随着标签页关闭而消失。

讨论要点:最有价值的质疑在于,这到底是不是全新的东西,还是只是一种更好的包装。Karpathy 下面的回复立刻追问,这和过去“tag 一个 agent”的做法究竟有什么区别;给出的答案集中在企业级部署、受限工具、记忆,以及多人连续协作,而不是基础聊天调用。

与前日对比:6 月 22 日已经出现团队工作区、记忆层和统一智能体 API。到了 6 月 24 日,这一趋势又向前推进一步,变成更像同事而不是标签页的共享、常驻团队界面。

1.2 运行框架与循环工程继续取代提示词技巧成为重点(🡕)

第二个主题是,当天真正的操作技能已经不是“把提示词写得更好”,而是设计循环、把状态外置、把工作流打包成 skills,并加上能跨运行保留的护栏。最强的证据,既来自高互动的解释帖,也来自互动量较低但很具体的实践者工作手册。

@akshay_pachaar 写道(797 点赞、37 回复、103,374 浏览、1,337 收藏),loop engineering 之所以重要,是因为否则人类仍然会被迫充当循环中的调度器和检查者。他在讨论串里直接点出了缺失部分:触发器、maker/checker 分离、磁盘持久化状态、明确的停止条件、通过 Graphiti 实现的时间性记忆,以及通过 Opik 实现的运行框架可观测性。

@swadeshkumar_ 认为(6 点赞、85 浏览),Claude Code 最适合运行在为智能体整形过的仓库里:简短的 CLAUDE.md 文件、可复用的 .claude/skills/、用于强制检查的 hooks,以及智能体能自行导航的文档,而不是把所有内容都塞进提示词。虽然这条帖子互动不高,但它把当天抽象的循环讨论翻译成了具体的仓库布局。

@charliejhills 整理 了一份包含 17 个链接的 Claude Skills 资源包(24 点赞、7 回复、3,161 浏览),其中包括 Anthropic 的《agent skills best practices》。此外,agent-skills 仓库 也把 skills 描述为面向生产的工作流打包形式,覆盖 spec、plan、build、test、review 和 ship 等 slash commands。

讨论要点:反复出现的细节是,状态必须存在模型之外。Akshay 讨论串下的一条回复说,关键不在于“一个长时间运行的智能体”还是“多个智能体”,而在于是否把目标、任务、状态、证据和退出条件保存在上下文窗口之外。

与前日对比:6 月 22 日的内容仍然更偏编排产品和模式目录。到了 6 月 24 日,重心明显转向模型外围的工程层:循环、文件、hooks 和 skills。

1.3 记忆、技能审查与最小权限控制正在成为明确的基础设施(🡕)

信息流也把几个过去较为模糊的智能体问题,变成了清晰的基础设施类别:可度量模块的记忆系统、面向第三方 skills 的安装时扫描,以及不是基于永久超权助手、而是从具体任务中推导作用域的授权模型。

@dair_ai 总结 了一篇长期记忆论文(128 点赞、14 回复、7,612 浏览、145 收藏),指出智能体记忆如今更像一层数据管理系统,包含存储、检索、更新、整合和生命周期治理。这个判断之所以重要,是因为它不再把端到端任务成功当成唯一指标,而是推动人们按模块来评估记忆系统。

共享的智能体记忆论文中的图表,展示长上下文临床咨询与降低幻觉任务上的模块级基准对比

@KentonVarda 认为(99 点赞、13 回复、6,818 浏览、78 收藏),显式地为每个智能体预配置权限,是错误的安全模型,因为它无法扩展。他提出的替代方案是能力安全(capability-based security):每个新任务都有自己的智能体,其权限从人类提供的具体资源中推导出来,而且智能体的全部权限都必须始终是人类权限的子集。

@JafarNajafov 重点提到 一组快速上升的仓库(9 点赞、718 浏览):用于 60-95% token 降低的 headroom、用于工程工作流打包的 agent-skills,以及用于安装前技能扫描的 SkillSpector。SkillSpector 的公开 README 表示,被扫描的 skills 中有 26.1% 含有漏洞,5.2% 显示出可能的恶意意图,这让安装 skills 更像是供应链安全问题,而不是随手分享提示包。

SkillSpector README 截图,展示漏洞比例以及扫描器对智能体技能风险的分类

@NostaIgicGareth 提到agentmemory(494 浏览),其公开仓库将自己定位为 Claude Code、GitHub Copilot CLI、Cursor、Gemini CLI、Codex CLI、Hermes、OpenClaw、pi 和 MCP 客户端的持久记忆层。README 中的徽章声称它可实现 95.2% 的 retrieval R@5 和 92% 的 token 降低,这与当天更广泛的趋势一致:让记忆既更便宜,也更持久。

讨论要点:围绕记忆和授权两类帖子,回复最终收敛到同一个原则:智能体不应该因为“看起来很聪明”就被信任。只有当记忆、权限和验证都被明确做出来时,它们才值得信任。

与前日对比:6 月 22 日已经把记忆和治理作为相邻问题提出。到了 6 月 24 日,这些议题变得更可操作:模块级记忆框架、安装时扫描器,以及明确的最小权限论证。

1.4 智能体产品继续扩展到销售、云运维、支付和研究(🡕)

最后一个主要主题是广度。当天的构建者不只是在发布编程助手,而是在把同样的智能体模式应用到外呼销售、云基础设施、机器支付和打包化研究服务中。

@austinh___ 宣布 一款面向外呼销售的聊天产品,可接入 40+ 数据源(219 点赞、56 回复、240,357 浏览、144 收藏)。这条帖子里最强的证据不是概念,而是运营数据:beta 前几周已完成 57,548 次查询,周环比增长 45%。

@mvcinvesting 报道称 Nebius AI Cloud 3.6 新增 Echo——一个用于基础设施控制的自然语言智能体,同时还加入 KMS、customer-managed encryption keys、Workload Identity Federation 和大容量存储升级(467 点赞、21 回复、30,593 浏览、33 收藏)。公开的 Nebius AI Cloud 3.6 发布报道与这一表述一致。

@ampersend_ai 解释 了一层基于 Amazon Bedrock AgentCore Payments 的按智能付费路由(7 点赞、386 浏览、3 收藏)。配套的 AWS 博文 描述了一种双跳支付流:智能体向 Ampersend 付款,Ampersend 再与上游模型提供商结算,同时把 x402、预算和审计能力都放在底层处理。

@Capafyai 推出 了 Deep Research Pro(125 浏览),把它做成一个可售卖的技能智能体,用于把问题转成带引用支撑的报告。公开的 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 提到 agentmemory(494 浏览),正是因为大家已经厌倦了每个会话都重讲一遍代码库。当前的应对模式很明确:持久记忆层、压缩上下文以及文件持久化状态。这个方向值得投入,因为多条互不相关的帖子都收敛到了同一个痛点。

当智能体一开始就拥有过大权限时,授权与安全都会失效

严重程度:高。 @KentonVarda 认为(99 点赞、13 回复、6,818 浏览、78 收藏),必须预先配置每个智能体的权限,这种做法既不具备扩展性,也会鼓励助手一开始就拿到过多访问权。@karpathy 讨论串下的一条回复 补充了 同样担忧的运营版本(7,076 点赞、389 回复、917,172 浏览、3,866 收藏):如果 Claude 是一个队友,它也需要 IAM、审计轨迹,以及在它做出昂贵操作前被干净地停下来的机制。由 SkillSpector 仓库(经 @JafarNajafov 提到,9 点赞、718 浏览)则在安装阶段加入了另一类安全抱怨:它声称扫描到的 skills 中 26.1% 含有漏洞,5.2% 显示出可能的恶意意图。今天的权宜方案,是加入扫描器、受限能力和明确的人类派生权限,而不是信任默认的广泛访问权。

生产级智能体仍需要围绕资金、云控制和可观测性补大量基础设施

严重程度:高。 @ampersend_ai 描述 了这样一种现实:每接一个收费模型或数据端点,开发者就得重新实现钱包托管、x402 支持、支出上限和账单集成(7 点赞、386 浏览、3 收藏)。@mvcinvesting 展示 了这样一点(467 点赞、21 回复、30,593 浏览、33 收藏):即便是云控制,也已经默认搭载 KMS、Workload Identity Federation 和预算控制,因为单纯的自然语言控制远远不够。@akshay_pachaar 也指出,可观测性必须能捕捉模型或提示词变化之后的运行框架漂移,而不只是确认某一次运行通过。这个方向看起来值得投入,因为同一天里,支付、云和循环管理帖子都暴露了同一种“额外接线工作”问题。


3. 人们期望的功能

能跨交接延续的共享、持久化智能体身份

最明确的现实需求,是一种更像持久队友、而不是一次性助手的智能体。@karpathy 目标状态描述为一个拥有工具和记忆、覆盖组织范围、异步运行的实体(7,076 点赞、389 回复、917,172 浏览、3,866 收藏);Anthropic 的 Claude Tag 公告 则进一步补充了频道作用域、环境更新和支出控制。@cryptoleek 则从编程侧展示 了同样的需求(77 浏览):在 PI WEB 中,会话可以跨浏览器关闭和机器切换继续存在。机会:直接。

原生嵌入仓库的工作流打包,而不是反复手把手盯着提示词

人们也明显需要可复用的工作流结构,来对抗提示词漂移。@swadeshkumar_ 主张 使用简短的 CLAUDE.md 文件、本地上下文文件、hooks 和 skills(6 点赞、85 浏览);@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 应用里的认证或计费一样“无聊但可靠”。@ampersend_ai 认为(7 点赞、386 浏览、3 收藏),开发者在发布智能体逻辑之前,不应该先去搭钱包托管和支出控制;@KentonVarda 则主张 采用能力范围受限的任务授权,而不是广泛的常驻权限。@JafarNajafov 又补充了 这一需求在安装阶段的版本,即 SkillSpector。机会:直接。


4. 使用中的工具与方法

工具 类别 评价 优势 局限
Claude Tag 团队智能体界面 (+) Slack 原生共享上下文、异步工作、频道级记忆、管理员控制 仍是 Beta 产品,也引发了“相比既有可 tag 智能体究竟新在哪”的疑问
Hermes Agent 个人智能体运行时 (+/-) 后台智能体、多 profile 工作流、skills hub、移动端消息入口 回复里仍在追问搭建摩擦、VPS 需求以及不同通道间的体验差距
Graphiti 记忆图谱 (+) 时间性上下文图、溯源、混合检索、不断演化的事实 需要多运营一层系统
Opik 可观测性/evals (+) Trace 捕获、评估、提示词与工具优化、生产监控 只有在团队为 harness 做了埋点并持续查看 trace 时才真正有用
agentmemory 持久记忆层 (+) 跨客户端记忆、压缩、MCP 支持、文件持久化召回 早期开源势头很强,但广泛的生产证据仍有限
headroom 上下文压缩 (+) 声称可降低 60-95% token,支持 library/proxy/MCP 模式、跨智能体记忆选项 压缩会新增一层需要团队信任和调优的预处理
agent-skills 工作流打包 (+) 开发生命周期 skills、slash commands、可复用质量闸门 赛道竞争激烈,质量仍取决于 skill 作者
SkillSpector 技能安全扫描器 (+) 安装前扫描、覆盖 17 个类别的 68 种模式、SARIF/JSON 输出 聚焦安装期审查;运行时滥用仍需额外控制
Nebius Echo / AI Cloud 3.6 云运维 (+/-) 自然语言基础设施控制,同时带 KMS、CMEK、WIF、存储和搜索升级 能力越强,接触生产前需要承担的治理负担也越重
PI WEB 智能体控制平面 (+) 持久会话、拆分进程 daemon、多设备监管、worktree 支持 仍偏向 Pi 单一智能体生态
Deep Research Pro / Capafy 研究技能 + 市场 (+/-) 带引用报告、多源抓取、可变现的技能分发、IP 保护 市场质量和可重复性仍是开放问题
Ampersend + AgentCore Payments 智能体支付 (+) 双跳按智能付费流程、预算、x402、统一提供商接入 依赖很多团队尚未具备的支付轨道与治理层

整体满意度更偏向那些能让智能体更可检查的工具:记忆层、skills、扫描器、trace 和受限控制平面。当一个产品要求用户信任高度自治,却没有同样强的护栏时,负面情绪就会更明显。

最清晰的权宜方案模式,是把关键状态和策略移出模型。团队把记忆存到磁盘或图数据库里,在上下文进入模型前先压缩它,把重复工作打包成 skills,并在智能体接触真实系统之前插入扫描器或支出控制。

工具组合里也显现出迁移压力。与其让一个昂贵助手包办所有事情,信息流越来越指向分层栈:一个像 Claude Tag 这样的团队协作界面、一个像 agentmemory 或 Graphiti 这样的记忆层、一个像 agent-skills 这样的工作流层,以及一个像 SkillSpector 或 AgentCore Payments 这样的安全层。


5. 人们在构建什么

项目 构建者 功能 解决的问题 技术栈 阶段 链接
Claude Tag @claudeai / @karpathy 共享的 Slack 原生 Claude 队友,具备受限频道、工具和异步任务 团队需要持久化、多玩家协作的智能体工作,而不是孤立聊天 Slack、组织级受限工具、频道记忆、管理员控制 Beta 推文, 公告
Claude for outbound sellers @austinh___ 可跨 40+ 数据源工作的 GTM 助手,通过聊天服务销售外呼 销售人员想要智能体式外呼帮助,但不想承担技术搭建成本 专有 app、40+ 数据源 Beta 推文
agentmemory @NostaIgicGareth / @ghumare64 为多个客户端上的编程智能体提供持久记忆 每个会话都重讲代码库会浪费 token 和注意力 iii engine、MCP、hooks、多客户端集成 Shipped 推文, 仓库
PI WEB @cryptoleek / jmfederico 面向长时间运行 Pi Coding Agent 会话的浏览器控制平面 会话通常会随着终端、浏览器标签页或机器交接而中断 Fastify Web/API 进程、会话守护进程、Pi SDK、git worktrees Beta 推文, 仓库
SkillSpector @JafarNajafov 提及的 NVIDIA 项目 在安装前扫描 AI agent skills 团队需要提前审查第三方 skills 中的漏洞和恶意模式 Python、OSV.dev、SARIF/JSON 输出、可选 LLM 分析 Shipped 推文, 仓库
Deep Research Pro on Capafy @Capafyai 把问题转成带引用支撑报告的研究 skill,并可作为服务出售 通用助手往往停留在浅层摘要,而创作者希望把更强的工作流变现 技能智能体、多源搜索/抓取、Capafy marketplace Beta 推文, Capafy skills, deep-research-pro
Ampersend @ampersend_ai 位于智能体和模型提供商之间的按智能付费路由层 智能体构建者不想为每个提供商都重复实现钱包托管、预算和支付编排 Amazon Bedrock AgentCore Payments、x402、Base 上的 USDC、提供商路由 Shipped 推文, AWS 博文

Claude Tag 是当天最明确的信号:智能体产品正在从个人效率工具走向共享的组织工作流。关键不只是“Slack 里的 Claude”,而是受限身份、共享可见性、异步跟进,以及 Anthropic 声称这一模式已经驱动其自身产品团队大部分代码产出。

agentmemory 和 PI WEB 从两个不同方向解决同一个“持久工作”问题。agentmemory 试图在多个编程客户端之间保留正确上下文,而 PI WEB 则让执行环境和会话守护进程持续存活,从而使工作本身能跨越前端会话。

SkillSpector、Deep Research Pro 和 Ampersend 则指向三种相邻的构建模式:一种把专业能力打包成可复用 skill,一种把这个 skill 作为具备 IP 保护的服务出售,另一种则补上计费和预算层,让自主智能体无需每次都手工搭建支付底层接线就能购买智能能力。


6. 新动态与亮点

Claude Tag 让“智能体作为同事”的界面形态变得具体

@karpathy 一次产品发布转成了当天最具定义性的框架转变(7,076 点赞、389 回复、917,172 浏览、3,866 收藏):智能体不再只是聊天对象,而是一个自包含、持久化、异步运行的队友。配套的 Anthropic 公告 补足了公开细节,使这一说法不只是营销文案:频道级身份、共享可见性、环境跟进、支出上限和日志。

安装时技能扫描成为一个可见的新类别

@JafarNajafov 提到SkillSpector(9 点赞、718 浏览),而仓库中“26.1% 被扫描 skills 含漏洞、5.2% 显示出可能恶意意图”的说法,给智能体工具链带来了一个具体的供应链安全数字。之所以值得注意,是因为讨论正在从“分享你的提示包”转向“安装前先把它扫一遍”。

由 AWS 支撑的智能体支付,从概念走向实现细节

@ampersend_ai 展示 了这样一点(7 点赞、386 浏览、3 收藏):按智能付费的基础设施,已经具体到足以写成 AWS 案例研究。配套的 AWS write-up 足够详细地铺开了支付管理器、双跳路由、预算和 x402 结算路径,因此人们可以把智能体商业看成真实基础设施,而不是只和加密概念沾边的想法。


7. 机会在哪里

[+++] 持久化智能体控制平面 —— 证据横跨 1.1、2 和 5:Claude Tag、Hermes 后台智能体、PI WEB 和 agentmemory 都指向同一种需求——会话、记忆和交接必须能跨越上下文丢失与设备切换继续存在。

[+++] 授权、扫描与支出治理层 —— Kenton Varda 关于最小权限的论证、SkillSpector 的漏洞主张、Nebius 的治理升级,以及 Ampersend 的支付预算,共同指向一个缺失栈层:对智能体能访问、购买和执行什么,必须有可信控制。

[++] 面向编程智能体的工作流打包 —— 当天关于 skills 的帖子、仓库结构建议和上升中的仓库,都显示出对可复用工程工作流的需求,以减少反复手把手盯着提示词。赛道已经开始拥挤,但需求既直接也很当下。

[+] 具备真实运营数据的垂直智能体应用 —— 面向外呼销售的产品声称 beta 阶段已完成 57,548 次查询、周增长 45%,这说明建立在丰富数据连接器之上的领域智能体仍有空间。这个机会正在浮现,但今天的证据数量仍少于基础设施主题。


8. 要点总结

  1. 重心已经转向持久化、共享式智能体工作,而不是孤立聊天会话。 Karpathy 的框架加上 Anthropic 公开的 Claude Tag 细节,把这个转变明确说了出来。(来源)
  2. 循环工程如今关心的是外部状态、检查者和 trace,而不只是更好的指令。 Akshay Pachaar 的讨论串把工作流与用于记忆的 Graphiti、用于可观测性的 Opik 绑在一起,而实践者的帖子则把它翻译成仓库结构和 skills。(来源)
  3. 记忆、权限和技能安全正在变成一等基础设施类别。 记忆论文讨论串、基于能力的授权论证、agentmemory 仓库,以及 SkillSpector 的扫描主张,都强化了同一个模式。(来源)
  4. 智能体商业化正在从编程扩展到云运维、支付、研究和销售。 Nebius、Ampersend、Capafy 和外呼销售产品都展示了围绕模型外层基础设施构建具体业务界面的方式。(来源)