Twitter AI Agent - 2026-06-20¶
1. 人们在讨论什么¶
1.1 Loop engineering 扩展成了 harness 和上下文层工作 (🡒)¶
最响的一组技术讨论依然围绕 loops，但 6 月 20 日的讨论更具体地落在了包裹这些 loops 的工程层面：harness 设计、evals、持久化上下文，以及控制系统。至少有 4 条强信号内容支撑了这个主题。
@0xMovez 分享了 Boris Cherny 的一句话（274 点赞、25 回复、56,401 浏览、545 收藏）：loops 的意义和从源代码走向智能体一样大，而他自己大约已有 30% 的代码完全由 loops 写成。真正特别的地方不只是这句口号；回复里马上把 loop-engineering 文章和 dynamic-workflow 讨论列成了严肃开发者的下一批必读材料。
@Vtrivedy10 认为（94 点赞、7 回复、8,216 浏览、147 收藏），好的 harness 应围绕 model-harness-task fit、evals、trace 检查，以及干净的按子任务划分的上下文窗口来构建。在回复里，他又补充说，越过那些容易拿到的早期收益后，后续进展主要取决于团队能否从 traces 中提炼出高质量的奖励信号和 evals。
@GergelyOrosz 观察到（110 点赞、25 回复、10,297 浏览、33 收藏），正在出现一波由 VC 支持或自举起步的尝试，目标都是为工程团队构建“context layer”。回复给出了一个很关键的细化：真正有价值的版本，不是对文档做一次性检索，而是能在多个会话和系统之间持续积累的持久化记忆。
@rohit_tiwari 提到免费的《Learn Harness Engineering》课程（37 点赞、4 回复、1,261 浏览、36 收藏），把 harness 工作定义为环境设计、状态管理、验证和控制系统，而不是调一调提示词。
讨论要点： 回复反复在强调同一条分界线：retrieval 不等于 memory，感觉对了不等于 evals，只有在有人明确管理上下文、traces 和失败分析时，loops 才会变得可靠。
与前日对比： 6 月 19 日让“loop engineering”成了信息流里的一个重要说法。到 6 月 20 日，这个话题已经延伸成公开课程，以及围绕工程团队 context layer 的更清晰市场类别。
1.2 智能体定义正在收敛到文件夹、markdown 和按需组件 (🡕)¶
第二个主题是，越来越多人认为，描述一个智能体最干净的方式，是把它写成目录里的文件，而不是藏在运行时打包层里。至少有 4 条内容支撑了这种收敛。
@rauchg 认为（546 点赞、60 回复、33,697 浏览、240 收藏），下一个热门编程语言会是 markdown，并展示了一个最小化的 eve 智能体：一个 agent/ 文件夹，里面有 instructions.md 和 skills/ 目录。在回复里，他还补充说，eve 暴露了一个有类型的 useEveAgent() hook 供自定义 UI 调用，这让这种文件夹布局不只是一个口号。
@hwchase17 重点提到了 Leve（49 点赞、6 回复、3,965 浏览、37 收藏），而公开的 Leve repo 把它描述成一个构建在 LangGraph 之上的、filesystem-first 的持久化智能体框架。repo 还补充了推文里只是一笔带过的实现细节：审批、subagents、connections、schedules、evals、沙箱算力和按调用方划分的安全控制，都被接进了这种基于目录的定义里。
@alex_prompter 整理了一串高 star repo（46 点赞、9 回复、3,306 浏览、89 收藏），它们的主要载荷是 markdown、skills 或 prompts，而不是运行时代码。虽然带有一些宣传意味，但这条帖子抓住了一个真实的分发模式：行为层本身已经开始作为独立 repo 被共享。
@sudoingX 称赞 Hermes Agent 新的 blank-slate setup 模式（76 点赞、12 回复、5,785 浏览、45 收藏）：默认智能体只带 provider、model、文件操作和 terminal，其余能力都按需再加回来。回复把这种吸引力说得很直白：用户先想要的是持久 shell 或 web fetch，而不是一个他们可能永远用不上的巨大全量预装界面。
讨论要点： 这种收敛不只是收敛到 markdown，而是收敛到可检查性。人们希望智能体定义存放在普通文件里，而且越来越偏好按需启用的工具，而不是一体化默认配置。
与前日对比： 6 月 19 日把编程智能体工作区当成操作系统来看。到 6 月 20 日，胜出的抽象又进一步收窄，变成文件树、skill 文件夹和最小默认安装。
1.3 通用智能体开始按能否完成真实工作流来被评判 (🡕)¶
第三个主题是，最强的工作流帖子谈的已经不只是代码生成，而是智能体能否跨服务、跨设备、跨渠道把事情真正做完。
@AlexFinn 说（198 点赞、34 回复、11,478 浏览、157 收藏），Codex 在大约 5 分钟里写好了一个新闻简报落地页、推送到 GitHub、创建了 Vercel 项目、连接 repo、选对域名并上线页面。后续最重要的信息来自回复：几位读者都说，更有意思的解锁方式，是先把枯燥的桌面和浏览器任务交给智能体，而不是只在工程场景里用它。
@IBuzovskyi 发布了 Hermes Agent v0.17（74 点赞、3 回复、10,678 浏览、58 收藏），新增 iMessage 支持、后台 subagents、图像编辑、automation blueprints、profile builder、skill-browser 安全扫描、原子化 memory 操作以及 dashboard 加固。这条讨论之所以重要，是因为它读起来像一份真正的发布说明，而不是模糊的产品预告。
@rabbit_hmi 推出了 rabbitOS 2.2（73 点赞、13 回复、9,083 浏览、22 收藏），其中包括 r1 上的 Claude Code sessions、terminal mode，以及用于保持连接到活跃工作的语音控制。这条推文值得注意的地方，不在于硬件图片本身，而在于它提出了这样一个判断：编程智能体会话现在已经被期待跟随用户进入环境型设备。
讨论要点： 最一致的怀疑并不是针对能力，而是针对割裂。Alex Finn 那条下面的回复在追问，用户到底要怎样把 Claude Code、Codex 和其他顶级工具接起来，而不是在它们之间不停切换。
与前日对比： 6 月 19 日把智能体工作区本身当成产品。到 6 月 20 日，这个工作区被进一步向外延伸到了浏览器、消息渠道、手机和语音控制硬件。
1.4 交易和智能体商业化的帖子依然活跃，但最好的证据来自开源框架和明确技术栈 (🡒)¶
信息流里关于交易和商业化的声音仍然很大，但最强的证据并不是“轻松赚钱”的口号，而是研究框架、具体技术栈图和上线机制。
@quantscience_ 分享了 TradingAgents（34 点赞、4 回复、3,124 浏览、52 收藏），公开的 TradingAgents repo 把它描述成一个多智能体交易框架，内含 analyst、researcher、trader、risk-management 和 portfolio-manager 等角色。论文的 arXiv 摘要写到，在采样实验中，这个框架在累计收益、Sharpe ratio 和最大回撤上都优于基线。
@cyrilXBT 拼出了一套 6 链接的自动交易开源栈（101 点赞、17 回复、5,783 浏览、85 收藏），组件包括 Lightweight Charts、CCXT、Hyperliquid's Python SDK 和 Tavily。这条讨论里最有价值的部分，其实是回复里的质疑：有读者说，光 Binance 的 rate-limit 问题就让他花了 3 天调试。
@slash1sol 宣布上线 Tiny Place（98 点赞、28 回复、5,222 浏览、72 收藏）：这是一个运行在 Solana 上的智能体实时社交经济系统，智能体可以发现 bounty、协商费用，并通过 x402 以 USDC 结算，同时把资金托管在 Phantom 钱包里。证据目前仍停留在上线初期，但它至少是一次明确尝试：让智能体成为市场参与者，而不只是聊天界面。
@Cryptic_Web3 报道（211 点赞、31 回复、20,748 浏览），aipaywithcrypto 融资 1,000 万美元，用于构建面向自主智能体的 AI 支付基础设施、市场平台和原生支付集成。
讨论要点： 最强的现实校准来自回复，而不是反对者。人们马上就在问，这些栈在真实环境里到底能不能赚钱，以及所谓“零成本”自动化在碰到限流和调试之后还能剩下多少。
与前日对比： 6 月 19 日关于商业化的讨论，重点还在审批、签名和证明。到 6 月 20 日，主题已经转向开源交易框架、智能体市场，以及支付轨道融资。
2. 令人困扰的问题¶
可靠的 harness 仍然依赖 traces、上下文纪律和人工审查¶
严重程度：高。@Vtrivedy10 说（94 点赞、7 回复、8,216 浏览、147 收藏），如果团队只是凭感觉去搭 harness，而不是用 evals、pass-rate 数据、token 消耗和 traces 来驱动，就会白白丢掉性能。@GergelyOrosz 补充了同一个问题的另一面（110 点赞、25 回复、10,297 浏览、33 收藏）：团队希望 Claude Code 知道邮件、Jira、tickets 和电话里有哪些信息，但真正难的是搭一个持久化的 context layer，而不是每个 session 都重新把窗口灌满。@rohit_tiwari 则把权宜方案定义为显式的环境设计、状态管理、验证和控制系统（37 点赞、4 回复、1,261 浏览、36 收藏）。这值得做，因为这种痛点在同一天里同时出现在一线实践笔记、市场需求和公开培训材料中。
一体化智能体配置仍然显得臃肿或彼此割裂¶
严重程度：中。@sudoingX 认为（76 点赞、12 回复、5,785 浏览、45 收藏），一个好用的智能体应该几乎从零开始，让操作者按需一个个加回工具，因为没用到的默认项会浪费上下文并让配置变得杂乱。回复里，人们点名了他们最先真正想要的那几样东西：持久 shell、web fetch，以及仓库专属的 MCP。类似的不满也出现在 @AlexFinn 那条帖子下面（198 点赞、34 回复、11,478 浏览、157 收藏），其中一条回复抱怨说，用户不停在 Claude Code、Codex 和其他顶级平台之间跳来跳去，却没有一种干净的方式把它们各自最好的部分组合起来。当前的绕行方案，是从极简底座开始，只把确实有必要的部分再搭回去。
交易智能体技术栈容易拼起来，却很难验证¶
严重程度：中。@cyrilXBT 分享了一套 6 个 repo 组成的自动交易开源栈（101 点赞、17 回复、5,783 浏览、85 收藏），但最有用的一条回复却说，哪怕只是只读同步，Binance 的 rate-limit 错误都让他花了 3 天调试。另一条回复更直接地点出了整条讨论回避的问题：到底有没有人真的做出了赚钱的 AI trader。@quantscience_ 提供了这个领域里更严肃的一面（34 点赞、4 回复、3,124 浏览、52 收藏）：一个有论文支撑、并明确区分 analyst、risk 和 portfolio-manager 角色的框架，而这本身就说明，临时拼凑的栈还远远不够。这看起来值得做，但买方会要求比大多数宣传帖更强的实盘验证和风险管理证据。
3. 人们期望的功能¶
能持续积累、而不是每个 session 都重新加载的持久上下文¶
最清晰的现实需求，是一个能跨工具、repo 和业务系统存活下来的记忆层。@GergelyOrosz 描述了工程团队正在集中寻找这种能力（110 点赞、25 回复、10,297 浏览、33 收藏），而一条回复把需求进一步说清：持久化和普通检索不是一回事。@milesdeutscher 分享了一个 Obsidian 加 Hermes 的方案（32 点赞、11 回复、2,651 浏览、41 收藏），把客户笔记、SOP、会议记录和业务决策都摄取进一个 “Business Brain”，作为今天的权宜路径。这是一个有即时工作流价值的现实需求。机会：直接。
可移植、可检查的智能体定义与 skills¶
几条最强的帖子都在追求同一种属性：智能体定义应该能以文件的形式被读取、编辑和迁移。@rauchg 把 eve 智能体压缩成 instructions.md 加一个 skills 文件夹（546 点赞、60 回复、33,697 浏览、240 收藏）；@hwchase17 指出了 Leve 这种 filesystem-first 的 LangGraph 框架（49 点赞、6 回复、3,965 浏览、37 收藏）；@sudoingX 则主张只在真正需要时再把工具加回来（76 点赞、12 回复、5,785 浏览、45 收藏）。@alex_prompter 还补充了一个证据：以行为层为主的 repo，如今已经成了真实的分发渠道（46 点赞、9 回复、3,306 浏览、89 收藏）。这是一个现实需求，而且已经有多种公开实现开始上线。机会：直接。
更安全的智能体原生商业与交易基础设施¶
信息流里带来的情绪承诺是“自主性”，但现实请求其实是“更安全的执行”。@quantscience_ 在 TradingAgents 里使用了 analyst、researcher、risk 和 portfolio-manager 等显式角色（34 点赞、4 回复、3,124 浏览、52 收藏），这说明严肃开发者已经需要很多结构化约束。@slash1sol 描述了一个具备自托管和直接结算能力的智能体市场（98 点赞、28 回复、5,222 浏览、72 收藏），而 @Cryptic_Web3 则强调了面向智能体支付轨道的融资（211 点赞、31 回复、20,748 浏览）。这是现实需求，但解法空间已经非常嘈杂，竞争也很激烈。机会：竞争激烈。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编程智能体 | (+) | 是 loop engineering、skills 和文件式智能体定义的核心参照点；现在也开始出现在 rabbit r1 这类设备表面上 | 用户仍然需要更好的 harness、context layer 和 token 控制来围绕它工作 |
| Codex | 通用智能体 | (+) | 借助浏览器和 computer use，可以跑完整个工作流，例如 GitHub push 加 Vercel deploy | 用户仍然需要把它和其他顶级智能体并行使用，而不是放在一个统一栈里 |
| Hermes Agent | 智能体运行时 | (+/-) | 支持 async subagents、iMessage、automation blueprints、profile builder、原子 memory 操作和 blank-slate setup | 表面能力扩张太快，反而催生了对极简安装和按需重加工具的需求 |
| eve | 智能体框架 | (+) | 定义极小，只需 markdown 和 skills；可部署到 Vercel，并带有供自定义 UI 使用的类型化 hook | 当天的证据主要还是早期产品叙事，而不是长期生产案例 |
| Leve | 智能体框架 | (+) | 在 LangGraph 上提供 filesystem-first 的持久智能体，支持 approvals、schedules、subagents 和 evals | 回复第一时间就问到了 schema drift 和并发目录变更问题 |
| Obsidian | 知识库 | (+/-) | 给智能体提供一个本地 vault，用于放 SOP、会议笔记和业务上下文 | 回复里有人对把客户笔记和业务记录交给 AI 感到隐私不适 |
| GLM 5.2 | 模型 | (+/-) | 在开源能力声明和通用应用 demo 中频繁出现，被视为有编程能力的开放模型 | 当天很多支撑证据仍偏轶事或宣传，而不是深度基准测试 |
| TradingView Lightweight Charts | 图表库 | (+) | 用于交易智能体前端的小型、高速 HTML5 金融图表 | 只解决可视化；执行和风险仍需额外组件 |
| CCXT | 交易所 API 库 | (+/-) | 为 100 多家交易所提供统一 API，适合交易 bot 和数据流水线 | 回复特别提到了实盘中的限流和调试痛点 |
| Tavily | 搜索 API | (+) | 官网强调安全、隐私和内容校验层，适合实时搜索 | 它只是支撑组件，不能替代交易逻辑或执行控制 |
整体满意度对模块化、可组合工具更正面，对大型打包式运行时则比较复杂。共同的权宜方案，是把智能体定义保存在文件里，只在需要时加工具，再用 traces 或显式角色让长工作流保持可理解性。迁移压力正在远离“一个巨大默认配置”，转向能叠在 Claude Code、Codex、Hermes 或自定义框架之上的可移植行为层。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| eve | @rauchg | 把智能体定义成一个由 instructions 和 skills 组成的小文件夹，可部署到 Vercel | 让智能体应用更容易检查、分享和部署 | Markdown files、skills folder、Vercel | Beta | tweet |
| Leve | @jit_infinity | 把一个文件目录编译成持久化的 LangGraph 智能体 | 给开发者一种 filesystem-native 的方式来加入 approvals、schedules、subagents 和 evals | Python、LangGraph、file-system agent spec | Alpha | tweet, repo |
| Hermes Agent v0.17 | @IBuzovskyi | 扩展一个多渠道运行时，加入 iMessage、async subagents、automation blueprints 和 profile builder | 让长时运行的智能体能跨消息、自动化和 dashboard 工作流运转，而不阻塞主 session | Hermes runtime、dashboard、skills/MCP integrations、Grok OAuth | 已发布 | tweet |
| TradingAgents | Tauric Research | 模拟一家交易公司，包含 analyst、researcher、trader、risk 和 portfolio-manager 智能体 | 为 LLM 交易工作流引入显式辩论和风险结构 | Python、多智能体 LLM 角色、带基准的研究框架 | Beta | tweet, repo, paper |
| Tiny Place | TinyHumans AI | 提供一个市场界面，让智能体发现 bounty、协商费用并以 USDC 结算 | 让智能体可以直接赚钱和交易，而不是被困在单一 app 里 | Solana、x402、Phantom，以及 Hermes 或 OpenClaw 之类的本地智能体栈 | 已发布 | tweet |
Leve 和 eve 之所以值得放在一起看，是因为它们展示了同一种构建模式的两种版本：把智能体定义保存在普通文件里，再让运行时围绕这个事实来源去编译或部署。区别只在侧重点：eve 更强调易用性，Leve 则更强调持久性、审批、调度和 evals。
Hermes Agent 的 v0.17 发布，是当天最清晰的证据之一，说明 runtime 构建者正在竞速把智能体 loops 变成完整操作表面。无需 Mac relay 的 iMessage 支持、可以稍后返回结果的后台 subagents，以及由 blueprint 驱动的调度，都在说明：智能体正在被设计成面向更长生命周期、更多渠道的工作，而不只是一个 terminal session。
TradingAgents 是金融这一簇里研究支撑最强的开发者信号。它的公开 repo 和论文描述了一种 team-of-agents 结构，里面有 analysts、看多和看空研究员、风险管理，以及最终的投资组合审批；和旁边那些“连上 6 个 repo 就开跑”的简化配方相比，这套架构显然具体得多。
纵观这些构建项目，反复出现的模式是显式角色加显式工件：文件、skills、schedules、traces 或风险层。即便是偏商业化的 Tiny Place，也把自己呈现成一个包含发现、协商和结算步骤的工作流界面，而不是一句 token 化口号。
6. 新动态与亮点¶
Skill-MAS 把编排知识当成文本工件，而不是权重更新¶
@dair_ai 分享了 Skill-MAS（57 点赞、6 回复、4,696 浏览、56 收藏），公开的 Skill-MAS arXiv 摘要写到，它试图解决一个反复出现的多智能体问题：如何在不微调前沿基础模型的前提下保留编排经验。论文的核心动作，是用多轨迹 rollout 和选择性反思在文本里演化一种元技能，这让它成了当天围绕智能体协调、而不是原始模型扩展的最清晰研究信号之一。
公开 harness 课程开始成为生态的一部分¶
@rohit_tiwari 带出了免费公开课程《Learn Harness Engineering》（37 点赞、4 回复、1,261 浏览、36 收藏）；与此同时，@alex_prompter 强调了另一波以 skills-first 和 markdown-first repo 为主的趋势（46 点赞、9 回复、3,306 浏览、89 收藏）。把这两者放在一起看，说明 harness 模式已经不再只是在团队内部摸索，而是开始被打包成可教学、可复制的公共工件。
7. 机会在哪里¶
[+++] 面向真实工程工作的持久上下文与验证层 —— 多个部分都给出了证据：@GergelyOrosz 描述了对工程上下文层的需求，@Vtrivedy10 描述了 harness 内部 trace 和 eval 的负担，而《Learn Harness Engineering》又把同样的需求打包成了公开课程。这个机会之所以强，是因为痛点同时出现在实践工作流、市场需求和培训材料里。
[++] 可移植的文件式智能体封装 —— eve 的文件夹布局、Leve 的 filesystem-first 框架、Hermes 的 blank-slate setup，以及各种 skills-first repo，都指向同一个需求：智能体定义要可检查、可编辑、可跨运行时迁移。这个机会强度中等，因为已经存在多种方案，但这种收敛本身就说明买方在乎这个抽象。
[+] 更安全的智能体原生交易与支付操作 —— TradingAgents、cyrilXBT 的开源栈、Tiny Place，以及 aipaywithcrypto 的融资轮，都说明围绕智能体交易和支付存在真实热度。它仍处于新兴阶段，因为讨论里最强的未解问题，依然是盈利能力、调试负担和实盘风险控制，而不是需求是否存在。
8. 要点总结¶
- Loop engineering 正在变成一门真实的操作纪律，而不只是一个说法。 当天最强的帖子把 loops 和 harnesses、evals、上下文窗口、持久化 memory 连在一起谈，而不是只谈提示词。(source)
- 大家偏好的智能体封装格式正在变得更简单、更可检查。 文件夹树、markdown 文件和 skill 目录，在 eve、Leve 以及 skills repo 讨论里反复出现。(source)
- 通用智能体越来越按能否跨表面并完成操作者工作来被评判。 Codex 跑完 GitHub 加 Vercel 的完整部署、Hermes 新增多渠道运行时能力，以及 rabbitOS 把 Claude Code 带到 r1 上，都符合这个模式。(source)
- 交易和商业化依然高热，但信号好坏参半。 更严肃的证据来自明确的框架和技术栈组件，而回复则不断把话题拉回到限流、调试痛点和实盘盈利的不确定性。(source)