Twitter AI Agent - 2026-06-20¶
1. 人们在讨论什么¶
1.1 循环工程扩展到 harness 与上下文层工作（🡒）¶
最热门的技术讨论仍围绕循环展开，但 6 月 20 日的话题更具体地落在围绕循环的工程工作上：harness 设计、评测、持久化上下文，以及控制系统。至少有四条高信号内容支撑了这一主题。
@0xMovez 分享（274 个赞、25 条回复、56,401 次浏览、545 次收藏）Boris Cherny 认为，循环带来的跃迁不亚于从源代码迈向智能体，而且他自己大约 30% 的代码已经完全由循环写出。特别之处不只在这句口号；回复区很快就把那篇循环工程文章和动态工作流讨论列为严肃构建者的下一份必读清单。
@Vtrivedy10 认为（94 个赞、7 条回复、8,216 次浏览、147 次收藏）指出，好的 harness 建立在模型、harness 与任务的匹配度、评测、轨迹检查，以及干净的分任务上下文窗口之上。他在回复中还补充说，过了那些容易拿下的早期收益后，后续进展主要取决于团队能否从轨迹中提炼出高质量的奖励信号和评测。
@GergelyOrosz 指出（110 个赞、25 条回复、10,297 次浏览、33 次收藏）提到，一波拿到风投或自筹资金的项目正试图为“工程团队构建上下文层”。回复里的关键细化是：真正有价值的形态，不是对文档做一次性检索，而是能跨会话、跨系统持续累积的持久化记忆。
@rohit_tiwari 提到（37 个赞、4 条回复、1,261 次浏览、36 次收藏）介绍了免费的 Learn Harness Engineering 课程，把 harness 工作定义为环境设计、状态管理、验证和控制系统，而不是单纯调提示词。
讨论洞察： 回复区反复划出同一条界线：检索不是记忆，凭感觉不是评测；只有在有人明确管理上下文、轨迹和失败分析时，循环才会变得可靠。
与前一日对比： 6 月 19 日，“循环工程”已经成为信息流中的重要说法。到了 6 月 20 日，这一概念进一步延伸为公开课程，以及围绕工程团队上下文层的更清晰市场类别。
1.2 智能体定义逐渐收敛到文件夹、Markdown 与按需组件（🡕）¶
第二个主题是，越来越多人认为，描述智能体最清晰的方式，是把它写成目录里的文件，而不是隐藏在运行时中的一组打包组件。至少有四条内容体现了这种收敛。
@rauchg 认为（546 个赞、60 条回复、33,697 次浏览、240 次收藏）称，下一门热门编程语言会是 Markdown，并展示了一个最小化的 eve 智能体：一个 agent/ 文件夹，里面包含 instructions.md 和一个 skills/ 目录。他在回复中补充说，eve 暴露了一个类型化的 useEveAgent() 钩子来构建自定义 UI，这让“文件夹布局”不只是个口号。
@hwchase17 强调（49 个赞、6 条回复、3,965 次浏览、37 次收藏）提到了 Leve；公开的 Leve 仓库 将其描述为一个基于 LangGraph、以文件系统为先的持久化智能体框架。仓库补足了推文中只是略微点到的实现细节：审批、子智能体、连接、调度、评测、沙箱计算，以及按调用方划分的安全机制，都被接入了这种基于目录的定义方式。
@alex_prompter 整理了（46 个赞、9 条回复、3,306 次浏览、89 次收藏）列出了一批高星仓库，它们的核心内容是 Markdown、技能或提示词，而不是运行时代码。尽管带有一定宣传意味，但这条帖子确实抓住了一个真实的分发趋势：行为层如今正作为独立仓库被分享。
@sudoingX 称赞（76 个赞、12 条回复、5,785 次浏览、45 次收藏）介绍了 Hermes Agent 新增的空白初始模式：默认智能体只带 provider、模型、文件操作和终端，其余功能都需要有意识地再加回来。回复也把这种吸引力说得很明确：用户首先想要的是持久化 shell 或网页抓取，而不是一个可能永远用不上的庞大预装功能面。
讨论洞察： 这场收敛不只是收敛到 Markdown，而是收敛到“可检查性”：人们希望智能体定义存在于普通文件里，也越来越偏好按需启用的工具，而非一体化默认配置。
与前一日对比： 6 月 19 日还把编码智能体工作区视作操作系统；到了 6 月 20 日，胜出的抽象进一步收窄到文件树、技能文件夹和最小默认安装。
1.3 通用智能体的评价标准，转向是否能完成真实工作流（🡕）¶
第三个主题是，最强的工作流相关帖子，已不再只是关于代码生成。更关键的是，智能体能否跨服务、跨设备、跨渠道把事情真正做完。
@AlexFinn 表示（198 个赞、34 条回复、11,478 次浏览、157 次收藏）称，Codex 写好了一个新闻简报落地页，把它推到 GitHub、创建 Vercel 项目、连接仓库、选对域名，并在大约五分钟内把页面上线。回复里的关键后续是：几位读者表示，更有意思的解锁点，是先让智能体处理那些枯燥的桌面和浏览器任务，而不是只把它留给工程工作。
@IBuzovskyi 发布了（74 个赞、3 条回复、10,678 次浏览、58 次收藏）介绍了 Hermes Agent v0.17：支持 iMessage、后台子智能体、图像编辑、自动化蓝图、配置档生成器、技能浏览器安全扫描、原子化记忆操作，以及仪表盘加固。这个线程之所以重要，在于它读起来像一份真正的发布说明，而不是模糊的产品预热。
@rabbit_hmi 推出了（73 个赞、13 条回复、9,083 次浏览、22 次收藏）介绍了 rabbitOS 2.2：在 r1 上支持 Claude Code 会话、终端模式，以及用于持续连接当前工作的语音控制。相比硬件图片本身，这条推文更值得注意的是它所传达的判断：编码智能体会话现在被期待能跟随用户进入环境式设备。
讨论洞察： 最一致的质疑不在能力，而在碎片化。Alex Finn 那条帖子的回复在问：用户究竟该如何把 Claude Code、Codex 和其他顶级工具连接起来，而不是不断在它们之间来回切换？
与前一日对比： 6 月 19 日还把智能体工作区本身当作产品；到了 6 月 20 日，这个工作区开始向外延伸到浏览器、消息渠道、手机和语音控制硬件。
1.4 交易与智能体商业化帖子依旧活跃，但最有力的证据来自开放框架与明确技术栈（🡒）¶
信息流里关于交易和商业化的讨论依然很热，但最强证据并非“轻松赚钱”式话术，而是研究框架、具体的技术栈图，以及清晰的发布机制。
@quantscience_ 分享（34 个赞、4 条回复、3,124 次浏览、52 次收藏）提到 TradingAgents；公开的 TradingAgents 仓库 将其描述为一个多智能体交易框架，包含分析师、研究员、交易员、风险管理和投资组合经理等角色。论文的 arXiv 摘要称，在所抽样的实验中，这个框架在累计收益、夏普比率和最大回撤上都优于基线。
@cyrilXBT 组装了（101 个赞、17 条回复、5,783 次浏览、85 次收藏）列出了一个由六个链接组成的自动化交易开源技术栈，其中组件包括 Lightweight Charts、CCXT、Hyperliquid 的 Python SDK 和 Tavily。这个线程最有价值的部分其实来自回复中的反驳：有读者说，光是 Binance 的速率限制问题，就耗掉了三天调试时间。
@slash1sol 宣布（98 个赞、28 条回复、5,222 次浏览、72 次收藏）提到 Solana 上的 Tiny Place，把它描述为一个面向智能体的实时社交经济体：智能体可以在那里发现悬赏、协商费用，并通过 x402 用 USDC 完成结算，同时将资产自托管在 Phantom 钱包中。证据仍停留在发布初期，但这确实是在尝试把智能体变成市场参与者，而不只是聊天界面。
@Cryptic_Web3 报道称（211 个赞、31 条回复、20,748 次浏览）称，aipaywithcrypto 已融资 1,000 万美元，用于建设面向自主智能体的 AI 支付基础设施、市场和原生支付集成。
讨论洞察： 最强的现实检验来自回复区，而不是唱反调的人。大家立刻追问：这些技术栈里有没有任何一个在真实环境下确实能赚钱？所谓“零成本”自动化，在碰上速率限制和调试后还能剩下多少？
与前一日对比： 6 月 19 日的商业化线程聚焦在审批、签名和证明；到了 6 月 20 日，重心转向开放交易框架、智能体市场，以及支付轨道融资。
2. 什么让人感到沮丧¶
可靠的 harness 仍依赖轨迹工作、上下文纪律和人工审查¶
严重程度：高。@Vtrivedy10 表示（94 个赞、7 条回复、8,216 次浏览、147 次收藏）指出，如果团队只是“凭感觉”做 harness，而不是用评测、通过率数据、token 消耗和轨迹来驱动，就会白白损失性能。@GergelyOrosz 新增了（110 个赞、25 条回复、10,297 次浏览、33 次收藏）则呈现了同一问题的另一种版本：团队希望 Claude Code 知道邮件、Jira、工单和通话里都有什么，但真正的难点在于构建持久化上下文层，而不是每次会话都把窗口重新加载一遍。@rohit_tiwari 将其定义为（37 个赞、4 条回复、1,261 次浏览、36 次收藏）把应对方案概括为明确的环境设计、状态管理、验证和控制系统。这个方向值得投入，因为同一天里，实践者笔记、市场需求和公开培训材料都指向了同一种痛点。
一体化智能体配置仍显得臃肿或彼此割裂¶
严重程度：中。@sudoingX 认为（76 个赞、12 条回复、5,785 次浏览、45 次收藏）指出，一个好用的智能体应该几乎从空白开始，让操作者按需逐个把工具加回来，因为没用到的默认功能会浪费上下文、让配置变乱。回复中，大家点名了自己真正想优先拥有的小集合：持久化 shell、网页抓取，以及仓库专属的 MCP。类似不满也出现在 @AlexFinn 表示（198 个赞、34 条回复、11,478 次浏览、157 次收藏）下面，有回复抱怨用户不断在 Claude Code、Codex 和其他顶级平台之间来回跳转，却没有一种干净的办法把各家的长处组合起来。当前的权宜之计，就是从最小基座出发，只把那些被证明确有必要的部分重新搭起来。
交易智能体技术栈易于拼装，却难以验证¶
严重程度：中。@cyrilXBT 分享（101 个赞、17 条回复、5,783 次浏览、85 次收藏）列出了一个自动化交易的六仓库开源技术栈，但最有价值的回复却说，即便只是只读同步，Binance 的速率限制错误也耗掉了三天调试时间。另一条回复则直接问出了整条线程都在回避的问题：到底有没有人真的做出能赚钱的 AI 交易员？@quantscience_ 提供了（34 个赞、4 条回复、3,124 次浏览、52 次收藏）展示了这个领域更严肃的一面：一个有论文支撑的框架，以及明确的分析、风险和投资组合管理角色。这本身就说明，临时拼装的技术栈并不够。这方向看起来值得投入，但买方期待的，将是比大多数宣传帖更强的实盘验证和风险管理证据。
3. 人们希望看到什么¶
能持续累积、而不是每次会话都重新加载的持久化上下文¶
最明确的实际需求，是一种能跨工具、跨仓库、跨业务系统存续的记忆层。@GergelyOrosz 介绍了（110 个赞、25 条回复、10,297 次浏览、33 次收藏）提到，一波项目正是为工程团队构建这样的能力；其中一条回复还把要求说得更清楚：要的是持久性，而不只是普通检索。@milesdeutscher 分享（32 个赞、11 条回复、2,651 次浏览、41 次收藏）展示了一套 Obsidian 加 Hermes 的方案：作为当前的替代做法，它把客户笔记、SOP、会议记录和业务决策摄入一个“Business Brain”中。这是个具有直接工作流价值的现实需求。机会：直接。
可移植、可检查的智能体定义与技能¶
几条最强帖子都在追求同一种属性：智能体定义应该能作为文件被读取、编辑和迁移。@rauchg 降低了（546 个赞、60 条回复、33,697 次浏览、240 次收藏）把 eve 智能体定义为 instructions.md 加上一个技能文件夹；@hwchase17 指出（49 个赞、6 条回复、3,965 次浏览、37 次收藏）指向 Leve 这种以文件系统为先的 LangGraph 框架；@sudoingX 认为（76 个赞、12 条回复、5,785 次浏览、45 次收藏）则主张只在真正需要时再把工具加回来。@alex_prompter 补充说（46 个赞、9 条回复、3,306 次浏览、89 次收藏）则证明，仅承载行为层的仓库如今已经成为真实的分发渠道。这是一个已有多个公开实现开始交付的现实需求。机会：直接。
更安全的原生智能体商业与交易基础设施¶
信息流里最打动人的承诺是自主性；最实际的诉求则是更安全的执行。@quantscience_ 使用了（34 个赞、4 条回复、3,124 次浏览、52 次收藏）展示了 TradingAgents 中明确的分析师、研究员、风险和投资组合经理角色，这说明严肃构建者已经需要相当多的结构化设计。@slash1sol 介绍了（98 个赞、28 条回复、5,222 次浏览、72 次收藏）提到一个支持自托管和直接结算的智能体市场，而 @Cryptic_Web3 强调（211 个赞、31 条回复、20,748 次浏览）则是智能体支付轨道的融资信号。需求很实际，但解法空间已经嘈杂且竞争激烈。机会：竞争性。
4. 正在使用的工具与方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Claude Code | 编码智能体 | (+) | 是循环工程、技能和基于文件的智能体定义的核心参照；现在也出现在 rabbit r1 这类终端表面上 | 用户仍需要围绕它构建更好的 harness、上下文层，以及更严格的 token 使用纪律 |
| Codex | 通用智能体 | (+) | 浏览器与计算机使用能力使其能完成 GitHub 推送加 Vercel 部署这类完整工作流 | 用户仍是在它和其他顶级智能体之间来回切换，而不是在一个统一栈内使用它 |
| Hermes Agent | 智能体运行时 | (+/-) | 异步子智能体、iMessage 支持、自动化蓝图、配置档生成器、原子化记忆操作，以及空白初始模式 | 功能面快速扩张，反而催生了对最小安装和按需加回工具的需求 |
| eve | 智能体框架 | (+) | 极小化的 Markdown 加技能定义，可部署到 Vercel，并提供用于自定义 UI 的类型化钩子 | 当前证据仍以早期产品叙事为主，而非长期生产案例 |
| Leve | 智能体框架 | (+) | 基于 LangGraph、以文件系统为先的持久化智能体，支持审批、调度、子智能体和评测 | 回复里立刻有人追问 schema 漂移和目录并发修改问题 |
| Obsidian | 知识库 | (+/-) | 为智能体提供本地 vault，用于存放 SOP、会议记录和业务上下文 | 回复提到，把客户笔记和业务记录交给 AI 处理会带来隐私不适 |
| GLM 5.2 | 模型 | (+/-) | 出现在开源能力声明和通用应用演示中，被当作具备编码能力的开放模型 | 当天大部分支撑证据仍是轶事或宣传，而非深度基准评测 |
| TradingView Lightweight Charts | 图表库 | (+) | 为交易智能体前端提供轻量、快速的 HTML5 金融图表 | 只解决可视化；执行与风险控制仍需单独组件 |
| CCXT | 交易所 API 库 | (+/-) | 为交易机器人和数据管道提供跨 100+ 家交易所的统一 API | 回复凸显了真实使用中的速率限制和调试痛点 |
| Tavily | 搜索 API | (+) | 官方站点强调实时搜索中的安全、隐私和内容验证层 | 它是辅助组件，不是交易逻辑或执行控制的替代品 |
总体来看，人们对模块化、可组合工具的满意度较高，而对大型捆绑式运行时的看法则较为复杂。常见应对模式是：把智能体定义保存在文件里，只在需要时添加工具，并用轨迹或明确角色让长工作流保持可理解。迁移压力正在从“一个巨大的默认配置”转向“可移植的行为层”，这些行为层可以叠加在 Claude Code、Codex、Hermes 或自定义框架之上。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| eve | @rauchg | 将智能体定义成一个包含指令和技能的小型文件夹，并可部署到 Vercel | 让智能体应用更易于检查、分享和部署 | Markdown 文件、技能文件夹、Vercel | Beta | 推文 |
| Leve | @jit_infinity | 将一个文件目录编译为持久化 LangGraph 智能体 | 为构建者提供一种文件系统原生的方式，以加入审批、调度、子智能体和评测 | Python、LangGraph、文件系统智能体规范 | Alpha | 推文, 仓库 |
| Hermes Agent v0.17 | @IBuzovskyi | 扩展多渠道运行时，加入 iMessage、异步子智能体、自动化蓝图和配置档生成器 | 让长时运行的智能体能覆盖消息、自动化和仪表盘工作流，而不阻塞主会话 | Hermes runtime、dashboard、技能/MCP 集成、Grok OAuth | 已发布 | 推文 |
| TradingAgents | Tauric Research | 模拟一家由分析师、研究员、交易员、风险和投资组合经理智能体组成的交易公司 | 为 LLM 交易工作流加入明确的辩论结构与风险结构 | Python、多智能体 LLM 角色、经基准验证的研究框架 | Beta | 推文, 仓库, 论文 |
| Tiny Place | TinyHumans AI | 创建一个市场界面，让智能体发现悬赏、协商费用并用 USDC 结算 | 让智能体能直接赚取收入和交易，而不是被困在单一应用内 | Solana、x402、Phantom，以及 Hermes 或 OpenClaw 等本地智能体栈 | 已发布 | 推文 |
Leve 和 eve 之所以值得放在一起看，是因为它们展示了同一种构建模式的两个版本：把智能体定义保存在普通文件里，再让运行时围绕这个真实来源去编译或部署。区别在于侧重点：eve 强调易得性，Leve 则更强调持久性、审批、调度和评测。
Hermes Agent 的 v0.17 发布，是运行时构建者正竞相把智能体循环变成完整操作界面的最清晰证据。无需 Mac 中继的 iMessage 支持、会稍后返回结果的后台子智能体，以及由蓝图驱动的调度，都说明智能体正被设计成面向更长生命周期、更多渠道的工作，而不再只是一个终端会话。
TradingAgents 是金融板块里研究支撑最强的构建者信号。其公开仓库和论文描述了一种团队式智能体结构，包含分析师、多头与空头研究员、风险管理以及最终的投资组合审批；相比旁边同时流传的那些“连上六个仓库就开跑”的配方，这一架构明确得多。
在这些项目中，反复出现的模式是“明确角色 + 明确产物”：文件、技能、调度、轨迹，或风险层。即便是偏商业化的 Tiny Place，也把自己呈现为一个包含发现、协商与结算步骤的工作流界面，而不只是一个代币化口号。
6. 新动向与值得关注的内容¶
Skill-MAS 把编排知识视为文本产物，而不是权重更新¶
@dair_ai 分享（57 个赞、6 条回复、4,696 次浏览、56 次收藏）提到 Skill-MAS，公开的 arXiv 摘要 Skill-MAS 表示，它试图解决一个反复出现的多智能体问题：如何在不微调基础前沿模型的前提下保留编排经验。论文的核心做法，是通过多轨迹 rollout 和选择性反思，以文本形式演化一种元技能；因此，它成为当天围绕智能体协同、而非单纯模型扩展的最清晰研究信号之一。
公开 harness 课程成为生态的一部分¶
@rohit_tiwari 发现了（37 个赞、4 条回复、1,261 次浏览、36 次收藏）提到免费的公开课程 Learn Harness Engineering，而 @alex_prompter 强调（46 个赞、9 条回复、3,306 次浏览、89 次收藏）则对应另一波以技能优先、Markdown 优先的仓库。合在一起看，这些帖子表明，harness 模式不再只是团队内部摸索出的经验，而是在被打包成可教学、可复制的公开产物。
7. 机会在哪里¶
[+++] Durable context and verification layers for real engineering work — Evidence came from multiple sections: @GergelyOrosz 介绍了 对工程上下文层的需求，@Vtrivedy10 介绍了 harness 中的轨迹与评测负担，以及 Learn Harness Engineering 这门公开课程，都把同一组需求指向了台前。之所以强，是因为这一痛点同时出现在实践者工作流、市场需求和培训材料中。
[++] 基于文件的可移植智能体打包 — eve 的文件夹布局、Leve 的文件系统优先框架、Hermes 的空白初始模式，以及技能优先仓库，都指向同一个共同需求：智能体定义应当可检查、可编辑，并可在不同运行时之间迁移。这一机会强度为中等，因为已有多种方案出现，但这种收敛本身就说明买方在意这一抽象。
[+] 更安全的原生智能体交易与支付操作 — TradingAgents、cyrilXBT 的开源技术栈、Tiny Place，以及 aipaywithcrypto 的融资轮，都表明市场对能交易、能支付的智能体确有真实热度。这一方向仍在萌芽期，因为讨论里最有力、却尚未被回答的问题，集中在盈利能力、调试负担和实盘风险控制，而不是需求是否存在。
8. 要点¶
- 循环工程正变成一门真正的操作性学科，而不只是一句口号。 当天最强的帖子把循环与 harness、评测、上下文窗口和持久化记忆联系在一起，而不只是提示词。（来源）
- 人们偏好的智能体打包形式，正变得更简单、更可检查。 在 eve、Leve 以及技能仓库相关讨论中，文件树、Markdown 文件和技能目录反复出现。（来源）
- 通用智能体越来越按是否能跨界面完成操作者工作来评判。 Codex 完成整套 GitHub 加 Vercel 部署、Hermes 增加多渠道运行时能力，以及 rabbitOS 把 Claude Code 带到 r1 上，都符合这一模式。（来源）
- 交易与商业化依然热度很高，但信号并不单一。 更严肃的证据来自明确框架和技术栈组件，而回复则不断把讨论拉回速率限制、调试痛点，以及对实盘盈利能力的不确定性。（来源）