Twitter AI Agent - 2026-07-11¶
1. 人们在讨论什么¶
1.1 运行框架工程正固化为面向仓库的操作系统 🡕¶
7 月 11 日最响亮的一组讨论并不是某个单一模型发布，而是大家正从提示词技巧转向为智能体打造仓库级操作系统：路由器、工作流文档、测试、审查通道、追踪，以及对“哪些系统本来就该执行动作”的明确界定。有 5 条内容分别提供了不同角度的证据。
@jamonholmgren 提出（680 点赞、35 回复、43,131 浏览、1,574 收藏），可靠的智能体式编程现在需要一个 AGENTS.md 路由器、可自我修复的文档、强制运行应用、端到端测试、自定义 lint、跨智能体审查、会话工作表、任务队列、性能检查，以及交班前的完整验证。最特别的一点在于，他把这些都视为同一个系统：智能体应当自己运行应用、边走边修问题，并留下足够的追踪状态，让另一个智能体或人类能在中途接手继续工作。回复里又补充了两个有用细节：确定性规则可以在 hook 阶段替代部分路由；遇到缺失工具时，应该把问题推入需要人工反馈的队列，而不是临场瞎编。
@dr_cintas 提到（621 点赞、51 回复、55,521 浏览、970 收藏），他目前最喜欢的工作流是让 Claude Fable 5 负责规格和审查，而让 Grok 4.5 通过 Grok CLI 负责落地开发。公开的 Fable Advisor README 与这种“架构师分工”模式一致，还额外加入了一条可选的 GPT-5.6 Sol 通道，用于对正确性要求极高的工作。回复里有人追问 Terra 和 Codex 版本，这说明实践者已经很快从“选一个通吃模型”转向“微调不同模型通道”。
@RoundtableSpace 推荐了 免费课程 《Learn Harness Engineering》（45 点赞、8 回复、48,238 浏览、21 收藏），而无论是截图还是首页，都展示出同样的公开教学结构：AGENTS.md、初始化、验证、可观测性，以及干净的交接。这很重要，因为关于运行框架的讨论正在变成可复用的培训材料，而不再只停留在小圈子讨论串里。
@heyitsurya 梳理了 LLM、智能体、智能体式工作流和多智能体系统之间的边界（39 点赞、3 回复、199 浏览、9 收藏）。附带的信息图之所以有价值，是因为它把每个标签都和自主性、控制方式、最适合的任务关联起来，让过度自动化的代价变得可见。
另一个规模更小但很具体的可移植性信号，来自 @ArchitectHappy_ 展示 的 wshobson/agents（18 点赞、8 回复、1,071 浏览、11 收藏）。README 写明，这个项目可从一份 Markdown 源文件生成 92 个插件、199 个智能体、162 个技能和 106 条命令，并覆盖 Claude Code、Codex、Cursor、OpenCode、Gemini CLI 和 Copilot。
讨论要点： 大家共同的动作，是把判断沉淀成能跨会话存活的文件和通道：路由、技能、hooks、追踪、规格和交接产物。
与前日对比： 7 月 10 日强调的是循环类型和对智能体友好的仓库布局；到 7 月 11 日，讨论进一步推进到了面向智能体的完整操作系统：路由器、审查通道、任务队列，以及可跨运行框架复用的脚手架。
1.2 图结构、记忆映射和规划架构比更大的模型更省钱 🡕¶
第二组讨论认为，真正的瓶颈不是缺少前沿智能，而是线性规划、重复发现仓库结构，以及高 token 开销的检索。研究、基准测试和代码记忆工具虽然角度不同，却都在论证同一件事。
@alex_verem 表示 《Atomic Task Graph》论文 显示，只要把工作分解成图而不是一条直线，7B-8B 的开放模型就可以在智能体基准测试中接近甚至超过 GPT-4（256 点赞、18 回复、36,635 浏览、433 收藏）。他强调的论点很具体：在 8B Llama 模型上，ATG 在 ALFWorld 上得分 63.65，而使用 ReAct 的 GPT-4 为 41.24；同时，幻觉动作比例从 43% 降到了 12%。
@0xSweep 认为 仓库记忆其实是同一个问题的缩小版：智能体每次都会从无状态开始，因此不断重读同样的文件（47 点赞、41 回复、4,603 浏览）。公开的 codebase-memory-mcp README 写道，它会构建一个本地 AST 和混合 LSP 知识图谱，覆盖 158 种语言、集成 11 个编程智能体，并把 5 个示例结构查询的 token 消耗从大约 412,000 降到约 3,400。回复里也给出了正确的保留意见：这个比例可能有挑选样本之嫌，但一个能在编辑后继续存活的解析式映射，与那种会逐渐腐坏的摘要式记忆层，确实是本质不同的东西。
@ArtificialAnlys 报告 称，Muse Spark 1.1 在其 Opencode 运行框架中的 Coding Agent Index 得分为 69，低于 Codex 中 GPT-5.5 medium 的 71，高于 Claude Code 中 Claude Opus 4.8 medium 的 67，且每个任务成本约为 1.4 美元（89 点赞、8 回复、6,564 浏览、10 收藏）。这张图之所以有信息量，在于它把得分与成本之间的取舍直接摆了出来；而回复里的关键提醒也很重要：这些排名衡量的是“模型 + 运行框架”的组合，所以那些接近前沿的截图，最终还是得放到买家的真实工作负载上重跑。
@NirantK 更直白地总结 了当天的结论：一旦任务走出 demo，确定性的上下文工程和成本纪律就会变得更重要，因此专用 harness 很可能会胜过通用包装器（58 点赞、8 回复、4,296 浏览、37 收藏）。
讨论要点： 大家共享的判断是，如今规划结构和检索结构的重要性，已经超过再多拿到一点模型分数。更好的任务分解、更便宜的查找，以及理解运行框架差异的评估，如今都成了经济优势。
与前日对比： 7 月 10 日已经在把评估和答案契约往生产环境推进；7 月 11 日则进一步加入了图规划和持久化代码映射，作为蛮力堆上下文和加大模型投入之外的具体替代方案。
1.3 智能体操作轨道正从 demo 走向可部署表面 🡒¶
最强的构建者动能，集中在那些让智能体能够发布应用、查询业务数据、持有持久状态，或部署到金融轨道上的基础设施。反复出现的词不是“人格”，而是 MCP 端点、仪表盘、钱包认证、发布控制和运行时队列。
@istdrc 开源了 Hands（23 点赞、3 回复、1,897 浏览、14 收藏）；公开的 README 和管理指南描述的是一个完整的客户端应用发布闭环：先草稿后发布、分阶段 rollout、分享页面、反馈工单和崩溃上报。这张截图之所以重要，是因为它把 Hands 展示成市场里的可安装应用，而不是一次性的原型。
@marclou 增加了 一个面向 TrustMRR 的 MCP 包装器，让智能体可以通过这个市场 API 查询创业公司营收、MRR 和营销渠道数据（181 点赞、40 回复、33,448 浏览、69 收藏）。TrustMRR API 文档写明，该服务提供由支付提供商记录支撑的经验证创业公司营收数据，而截图则展示了一个指向 https://trustmrr.com/api/mcp. 的 MCP 客户端配置。
@NavenNetwork 介绍了 Naven Workspace——这是一个由钱包支撑的空间，可在 Robinhood 驱动的轨道上创建、配置并部署智能体，底层编排由 OpenClaw 负责（68 点赞、17 回复、5,332 浏览）。界面截图让这个叙述非常具体：连接工作区、选择运行时、部署机器，然后监控实时运营。
@mnemeDB 宣布 mneme-mcp 已上线（94 点赞、8 回复、565 浏览）；公开的 Mneme README 写道，这个产品会为每个智能体提供独立的 Postgres schema、钱包认证、向量搜索和原生 MCP 数据访问。npm 页面截图也清楚展示了它的卖点：装一次之后，就让 Claude、Cursor 或其他 MCP 客户端直接调用原生数据库工具，而不是再套一层记忆服务包装器。
讨论要点： 大家的共同产品语言，并不是为了自主而自主，而是“轨道”：发布、营收数据、部署、金融，以及智能体能够通过结构化表面直接触达的持久状态。
与前日对比： 7 月 10 日已经出现了 CoinMarketCap Agent Hub 和发布仪表盘这类可安装控制表面；7 月 11 日则把这股能量进一步收束到了更偏运营底座的方向：业务数据 MCP、钱包支持的数据库，以及把部署与金融放在一起的工作区。
1.4 治理、契约和托管式多智能体运行时仍是闸门层 🡕¶
即使在一个明显偏构建者的样本集中，最冷静的帖子还是不断回到同一个问题：生产采用的阻碍，与其说来自原始模型输出，不如说来自治理、问责，以及对智能体系统行为的明确控制。
@michaeljburry 分享了 一位实践者的看法：大规模智能体式 AI 需要编排、上下文工程、状态管理、多智能体协作、安全和合规层，但更难的问题其实是治理和文化（457 点赞、80 回复、91,142 浏览、172 收藏）。回复立刻强化了问责这一点：最终还是得有人对智能体的决策和失败模式负责。
@SciFi 提到了 论文 《From Prompts to Contracts》（1 点赞、119 浏览、3 收藏）；无论是截图还是摘要，都异常具体地说明了一个企业级 harness 应该编码什么：来源边界、实体路由、答案契约，以及围绕可替换模型边界的可复现实验追踪。与普通的治理讨论串相比，这是更强的证据，因为它把要求变成了由代码持有的工件和固定的验证场景。
@seratch 指出，OpenAI 的 Responses API 现在已在 beta 中支持基于 GPT-5.6 模型的多智能体运行（9 点赞、814 浏览、4 收藏），而文档写明，根智能体可以生成并行子智能体、给它们发消息、打断它们，并设置并发上限。它和当天其他讨论的联系很重要：托管式多智能体恰好在实践者越来越坚持显式路由、可追踪性和受限角色的同时到来。
讨论要点： 无论是企业讨论串、研究还是 API 文档，大家想要的控制表面都非常明确：具名智能体、具名契约、具名追踪、具名责任人。
与前日对比： 7 月 10 日的路由争论，大多还停留在 UI 默认值和模型选择器；7 月 11 日的治理层则更深入：谁被允许执行动作、哪些答案在结构上被允许，以及一次最多能运行多少个子智能体。
2. 令人困扰的问题¶
无状态的仓库探索仍在烧钱又耗时¶
高严重度。@0xSweep 描述了 一种熟悉的失败模式：编程智能体会反复搜索同一个仓库，因为它们在不同会话之间记不住代码库，从而把最基础的结构问题也变成巨额 token 账单（47 点赞、41 回复、4,603 浏览）。@jamonholmgren 则展示了 运营侧的手工补救方案（680 点赞、35 回复、43,131 浏览、1,574 收藏）：可自我修复的文档、追踪、任务队列和显式路由，好让下一次运行不必从零开始。人们现在用代码映射、更好的文档和更多仓库侧记忆来应对。这个方向值得做，因为实践者和工具构建者都在指向同一种税负：重复发现，却不产生任何用户价值。
可靠的智能体工作仍然需要太多手工脚手架¶
中高严重度。当天传播最广的建议，本质上就是一张超长配置清单。@jamonholmgren 列出了 路由器、hooks、linters、多智能体审查、工作表、基准测试和夜班技能，作为基础设施；而 @RoundtableSpace 推荐 的，则是一整门免费的运行框架工程课程（45 点赞、8 回复、48,238 浏览、21 收藏），专门教人如何把这些东西做好。即便是可移植性的答案 wshobson/agents，存在本身也是因为团队不想为每个运行框架反复重建同一套脚手架。人们现在靠课程、插件市场和复制仓库模板来应对。这个方向值得做，因为需求已经非常明显，但配置过程看起来仍像是定制化的仓库木工活。
治理与问责仍比原始编码输出更难¶
高严重度。@michaeljburry 说（457 点赞、80 回复、91,142 浏览、172 收藏），在生产级智能体系统里，治理和文化比技术底座更难；回复则聚焦于谁该为智能体行为负责。论文 《From Prompts to Contracts》 由 @SciFi 在这里 提到，它则把同样的挫败感推进到了架构层：如果没有来源边界、答案契约和可复现实验追踪，提示词加检索的原型根本撑不到产品化。人们现在靠手工审查、显式边界和固定验证场景来应对。这个方向值得做，因为这个阻碍同时出现在实践者证词和正式研究中。
基准截图和路由信号仍然很容易被误读¶
中等严重度。@ArtificialAnlys 发布了 一张干净的得分与成本图，但最有价值的回复，是提醒大家每个分数都把模型和其运行框架打包在了一起。@dr_cintas 展示了 一套 Fable 加 Grok 的混合工作流，回复马上就有人追问 Terra 和 Codex 版本，这也说明路由选择仍然是手工且未定型的。人们目前靠重跑本地评估，再把架构师和开发执行角色拆分给不同模型来应对。这个方向值得做，因为市场仍缺少能够比排行榜截图更好迁移的、面向具体工作负载的路由与评估层。
3. 人们期望的功能¶
面向智能体的仓库操作系统¶
最清晰的期待并不是更聪明的提示词，而是一套可重复的系统。@jamonholmgren 描述了 由路由器、文档、测试、追踪、审查通道和性能检查组成的一整套栈；@RoundtableSpace 把人们引向了一整门运行框架工程课程；而 wshobson/agents 则打包了一个跨运行框架市场，因为团队显然不想再手工搓一遍相同的脚手架。真正的现实需求，是一套开箱即带路由、验证、交接和可观测性的起步系统。机会评级：[+++] 直接。
能跨会话和编辑持续存在的持久代码记忆¶
这种需求表达得非常明确。@0xSweep 把重复的仓库再发现定义为纯粹浪费，而 @jamonholmgren 之所以把文档和追踪视作记忆基础设施，恰恰是因为会话记忆并不可靠。人们似乎真正想要的是一层低成本的结构化记忆层：它能与代码库保持同步、对人类可见，并防止智能体为仓库早已知道的东西重复付费。机会评级：[+++] 直接。
面向发布、数据、部署和金融的智能体底座¶
当天几位构建者真正想要的，其实都是围绕行动的可靠轨道。Hands 把发布操作变成可见工作流，TrustMRR 通过 API 和 MCP 模式暴露经验证的创业数据，Naven Workspace 把部署与资金放进同一个智能体工作区，而 Mneme 则把持久状态推进到带钱包认证的 Postgres schema 中。现实需求是这样一类智能体原生底座：它们比定制胶水更容易集成，却又比让模型直接对原始系统即兴发挥更安全。机会评级：[++] 直接。
契约驱动的治理与路由策略层¶
最严肃的企业需求，是那种能在模型替换后仍然成立、并能越过 demo 扩展的策略层。@michaeljburry 把治理和问责视为瓶颈，《From Prompts to Contracts》 把这个瓶颈具体化成显式答案契约和追踪，而 @dr_cintas 以及 @seratch 则表明，跨模型和跨子智能体的路由已经在变成一等问题。现实需求是策略引擎：决定该由谁执行动作、该走哪条模型通道、什么样的证据才算过关，以及如何让整次运行保持可审计。机会评级：[++] 直接。
4. 使用中的工具与方法¶
| 工具 | 类别 | 评价 | 优势 | 局限 |
|---|---|---|---|---|
| Fable Advisor | 路由与编排插件 | (+) | 让 Fable 5 负责规格和审查，同时把开发执行路由到 Grok 4.5 或 GPT-5.6 Sol 等更便宜的模型通道；内置跨厂商审查 | 需要多个厂商 CLI，并且要显式配置通道 |
| Learn Harness Engineering | 课程与参考资料 | (+) | 提供围绕 AGENTS.md、初始化、验证和交接的公开讲座、项目与模板 | 属于教学材料，不是开箱即用的运行时 |
| codebase-memory-mcp | 本地代码记忆 MCP | (+) | 本地 AST 与混合 LSP 图谱；支持 158 种语言；结构查询快；可大幅节省仓库探索 token | 在更大的仓库里收益最明显；用户仍需在自己的工作负载上验证宣称效果 |
| Artificial Analysis Coding Agent Index | 基准测试套件 | (+/-) | 把任务得分和单任务成本合并成一张直观图表 | 模型与 harness 被绑定在一起，因此排名无法直接迁移 |
| Atomic Task Graph | 规划框架 | (+) | 图分解、并行分支和分支内修复可在无需额外训练的情况下改进智能体规划 | 研究成果，不是现成可用的生产工具 |
| OpenAI Responses Multi-agent | API 与运行时 | (+) | 托管式子智能体生成、消息传递、等待和并发控制 | 仍是 beta；会增加 token 成本，并需要受限的并行任务 |
| Hands | 发布平台 | (+) | 支持先草稿后发布、分阶段 rollout、分享页面、反馈工单和崩溃循环 | 聚焦点较窄，只覆盖客户端应用发布操作 |
| TrustMRR API plus MCP pattern | 结构化业务数据 | (+) | 提供经验证的创业公司营收数据、MRR 与要价筛选，并具备 MCP 就绪的访问路径 | 需要 API key，且仅限单一业务数据领域 |
| Mneme and mneme-mcp | 智能体数据库与记忆层 | (+) | 真实的 Postgres schema、钱包认证、向量搜索和原生 MCP 访问 | 早期产品，且带有较强的加密领域定位 |
| Naven Workspace | 部署与金融工作区 | (+/-) | 钱包支撑的工作区、运行时选择、部署流程和实时运营框架 | 新产品表面，依赖链上环境和运行时 |
| Agentic Plugin Marketplace | 跨 harness 脚手架 | (+) | 一份 Markdown 源文件即可向主流编程 harness 生成插件、agents、skills 和命令 | 目录庞大，能力虽强，但策展与维护复杂 |
整体满意度最高的时候，通常是某个工具消除了一个具体的运营税负：token 消耗、发布摩擦、缺少业务数据，或跨 harness 重复建设。常见的权宜方案，是让一个高判断力模型继续掌舵，把大量工作推给更便宜的模型或确定性基础设施，并把更多系统能力暴露成文件、MCP 或仪表盘，而不是把一切都困在一个聊天循环里。
因此，迁移压力看起来已经不再像“把供应商 A 换成供应商 B”，而更像“别再依赖裸露的补全能力”。真正获得牵引力的工具，是那些在模型外围增加了路由、记忆、发布控制或结构化 API 的产品。
5. 人们在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Fable Advisor | DannyMac180 | Claude Code 插件，让 Fable 5 负责架构与审查，同时把开发执行路由到更便宜的模型通道 | 在不放弃强规划器的前提下降低成本，并加入跨厂商审查 | Claude Code 插件；Fable 5；Grok CLI；Codex CLI | Beta | tweet, repo |
| codebase-memory-mcp | DeusData | 本地代码智能 MCP，把仓库索引成持久知识图谱 | 让智能体不必在每个会话里重读整个代码库 | C；tree-sitter；混合 LSP；本地 MCP | Shipped | tweet, repo |
| Hands | botiverse | 面向客户端应用的发布平台，支持草稿构建、rollout、分享链接、反馈和崩溃循环 | 为智能体和团队提供一个受控的构建后发布表面 | Cloudflare Workers；D1；R2；移动端与 Electron SDK | Shipped | tweet, repo, site |
| TrustMRR MCP | @marclou | 对 TrustMRR 经验证创业数据 API 的 MCP 包装器 | 让智能体按营收、MRR 和营销渠道查询收购目标，而不是去抓取网页 | Public API；MCP；计划中的 ChatGPT app | Beta | tweet, API docs |
| Naven Workspace | @NavenNetwork | 由钱包支撑的工作区，用于在 Robinhood 驱动的轨道上部署和运营智能体 | 简化自主商业场景中的智能体部署、资金配置和实时运营 | Workspace UI；OpenClaw runtime；USDG funding；x402-native workflows | Beta | tweet |
| mneme-mcp | mnemedb | 原生 MCP 的 Postgres 记忆与数据库层，带钱包认证和向量搜索 | 给智能体提供真实 schema 和持久状态，而不是一个固定的记忆桶 | Postgres；pgvector；钱包认证；MCP | Beta | tweet, repo |
| Agentic Plugin Marketplace | wshobson | 一份 Markdown 源文件生成的跨 harness 插件、智能体、技能和命令市场 | 避免为每个 CLI 或 harness 反复重建相同的智能体脚手架 | Markdown 源文件；适配 Claude Code、Codex、Cursor、OpenCode、Gemini 和 Copilot | Shipped | tweet, repo |
Fable Advisor 和 codebase-memory-mcp 从两个不同端点解决同一个成本问题。前者把高 token 开销的开发工作从最昂贵的模型上分流出去，后者则把仓库结构转成一张本地图谱，从根本上消除不必要的检索 token。
Hands、TrustMRR MCP、Naven Workspace 和 mneme-mcp 都更像是操作底座，而不是面向终端用户的聊天产品。反复触发它们的原因在于，构建者希望智能体能通过结构化接口去发布、查询业务数据、部署，或者持有持久状态，同时这些接口仍然可以被人类检查和治理。
跨运行框架脚手架模式同样值得注意。Agentic Plugin Marketplace 之所以存在，是因为团队希望把路由原则、专家技能和可复用智能体一起带着走，跨越 Claude Code、Codex、Cursor、Gemini、OpenCode 和 Copilot，而不是在每个平台上都从零开始。
6. 新动态与亮点¶
《Atomic Task Graph》让“更聪明的规划、更小的模型”变成了可衡量的主张¶
真正让它值得注意的，是它的具体性。@alex_verem 强调了 《Atomic Task Graph》论文（256 点赞、18 回复、36,635 浏览、433 收藏）；论文声称，图分解和分支内修复能让 7B-8B 模型在 ALFWorld 上击败使用 ReAct 的 GPT-4，同时大幅减少幻觉动作。这把“更好的规划会更强”这种熟悉直觉，变成了公开可对照的基准结果。
OpenAI 的 Responses API 在 beta 中正式把托管式多智能体带上台面¶
@seratch 指出，OpenAI 已为 Responses API 加入多智能体支持，而beta 文档详细列出了根智能体生成、子智能体消息传递、等待、中断和并发限制。这值得注意，因为当天许多实践者模式仍然要手工跑通；而在这里，平台本身已经开始吸收这部分编排工作。
《Learn Harness Engineering》把社交媒体热梗变成了公开课程体系¶
@RoundtableSpace 分享了 免费课程 《Learn Harness Engineering》（45 点赞、8 回复、48,238 浏览、21 收藏）。这个网站之所以值得注意，是因为它把围绕 AGENTS.md、初始化、验证、可观测性和交接的讲座、项目与可复用模板打包在一起，意味着这门方法如今正被当作一种工程方法来教授，而不再只是靠经验贴互相传递。
《From Prompts to Contracts》为企业级运行框架提供了具体架构¶
@SciFi 提到了 《From Prompts to Contracts》，这篇论文之所以值得注意，是因为它点名了真正的企业原语：来源边界、实体路由、答案契约、验证工件和可复现实验追踪。它是这份数据集中最清楚地把可靠性从一种愿景，推进为可检查结构的条目之一。
7. 机会在哪里¶
[+++] 面向编程智能体的仓库操作系统 —— @jamonholmgren、《Learn Harness Engineering》、Fable Advisor 和 wshobson/agents 都在指向同一个缺口：团队希望路由、验证、可观测性和交接可以预先组装好，而不是每个仓库都重建一遍。这个机会很强，因为需求在同一天里同时以痛点和主动造工具两种形式出现。
[+++] 持久代码记忆与结构化检索层 —— @0xSweep 明确点出了 token 浪费，而 《Atomic Task Graph》 和 @jamonholmgren 都在强化围绕上下文建立更好结构这一更广泛的需求。这个机会很强，因为它解决的是重复、昂贵的工作流税负，而不是一个猜想式功能请求。
[++] 面向发布、营收数据、部署和持久状态的智能体底座 —— Hands、TrustMRR API、Naven Workspace 和 Mneme 都揭示了同一个机会：用结构化表面让智能体做真实工作，而不必对原始系统即兴发挥。这个机会属于中等强度，因为需求很具体，但每个类别都伴随着信任、集成和领域约束。
[++] 基于契约的治理与路由策略服务 —— @michaeljburry、《From Prompts to Contracts》、@dr_cintas 以及 OpenAI 的多智能体文档 都在用不同方式说同一件事：总得有人决定该走哪条通道、什么证据算数，以及整次运行如何保持可审计。这个机会属于中等强度，因为需求显而易见，但买家通常会是严肃团队，而不是普通用户。
[+] 理解 harness 的基准测试与评估产品 —— @ArtificialAnlys 提供了图表，而它的回复则指出了机会：团队需要能区分模型质量与 harness 质量、并且能反映自身工作负载的评估，而不是一张通用排行榜。这个方向还处于早期，因为市场显然想要这种洞察，但解决方案空间仍在成形。
8. 要点总结¶
- 重心已经从提示词转向仓库工件。 当天传播最广的建议，把 AGENTS.md 路由器、可自我修复文档、测试、追踪和任务队列视为可靠编程智能体的真正底座，而不是可有可无的润色。(source)
- 如今控制成本，意味着要改运行框架，而不只是换模型。 Fable Advisor 把判断与敲代码拆开，codebase-memory-mcp 则是把仓库结构转成本地图谱，从而解决重复检索的浪费。(source, repo)
- 结构化规划和检索，如今已是蛮力扩张之外可信的替代路线。 《Atomic Task Graph》主打图分解和分支内修复，代码记忆工具主打持久结构化查找；两者都在试图减少上下文膨胀，而不是继续砸钱硬堆。(source)
- 真正获得牵引力的构建者，交付的是轨道，而不是人格。 Hands、TrustMRR MCP、Naven Workspace 和 mneme-mcp 都在把发布、业务数据、部署或持久状态包进智能体可以直接使用的结构化接口。(source)
- 基准测试和企业论文如今都认同：运行框架是产品的一部分。 排行榜仍把模型和脚手架绑在一起，而企业级可靠性也越来越意味着契约、追踪、边界和显式路由，而不是盲目信任模型。(source, paper)