Twitter AI 编程 - 2026-06-03¶
1. 大家在讨论什么¶
1.1 Agent 管理器不再只是独立的 IDE 功能，而是整合枢纽 🡕¶
最强烈的 Antigravity 信号，已经不再是“存在一个以 Agent 为先的 UI”，而是管理器这一层如今必须协调多个模型、多个界面和外部工具。三条保留内容支撑了这一主题。
@kevinhou22 解释了（255 个赞、45 条回复、14,884 次浏览、97 次收藏）解释了 Antigravity 为什么把 IDE 与 Agent Manager 拆分开。帖子称，这一品类已经从自动补全演进到聊天，再到 Agent 和多 Agent；如今，用户不再停留在单一编辑器内，而是在 IDE、Agent Manager、SDK 和 CLI 之间管理“几十个甚至上百个 Agent”。
@FlutterDev 分享了（70 个赞、3 条回复、3,019 次浏览）是一场关于使用 Antigravity 和 Flutter 构建应用的 Google I/O 演讲回放。公开的 Flutter Antigravity 文档 现在推荐以审查为驱动的开发、Dart 和 Flutter 扩展、MCP 服务器配置以及 Agent 式热重载，使围绕管理器的讨论从主题演讲里的愿景，变成了有文档支撑的应用开发工作流。
@PDBeurope 展示了（6 个赞、1 条回复、711 次浏览、9 次收藏）指出，PDBe MCP Servers 不仅能与 Antigravity 协作，也能与其他兼容 MCP 的客户端协作。公开的 PDBe MCP Servers README 同时提供了 Antigravity 原始配置和 Codex CLI 示例，说明这一协议层可以跨不同编程界面移植。
讨论洞察： kevinhou22 线程中最有价值的回复，要求由更强的监督模型调度更便宜的子 Agent，并实现 Antigravity IDE 与 Agent Manager 之间的对话同步。大家要的不是更好的自动补全，而是更好的编排能力。
与前一天对比： 6 月 2 日的重点是管理器界面本身。6 月 3 日则新增了整合文档、MCP 可移植性，以及对跨界面状态同步和混合模型路由的具体诉求。
1.2 Codex 进一步进入特定角色的应用构建，但首批实现仍显粗糙 🡕¶
第二大主题是 Codex 正在扩展到工程开发之外，而用户也立刻开始对这些新界面的体验和可靠性进行压力测试。五条保留内容支撑了这一主题。
@Nikitont 总结了（12 个赞、3 条回复、123 次浏览、5 次收藏）介绍了 6 月 2 日 Codex 更新中的六个新插件、Sites，以及面向分析、设计、销售和财务工作的注释功能。这一点之所以重要，是因为当天其余证据表明，这些能力已经被用于真实工作流，而不只是停留在发布帖的宣传里。
@CiscoAI 表示（27 个赞、1 条回复、69,230 次浏览）指出，App Builder 将 Codex 直接引入 Cisco Cloud Control，让客户和合作伙伴可以用自然语言为自己的环境创建定制应用。这是 Codex 正从单纯的编程助手转向内部应用构建界面的最明确企业信号。
@IShmool 报道称（4 个赞、2 条回复、104 次浏览）介绍了使用 Wix Headless Codex 插件搭建摩托车商店的过程，包括 20 个产品、35 张 AI 生成的产品图片、通过 Wix Blog API 生成的博客内容、购物车和结账功能、CRM 流程，以及 PageSpeed 得分：性能 96、无障碍 100、最佳实践 100、SEO 100。其独特之处在于运营层面：“周二早上，店铺经理打开 Wix Dashboard，就能自己管理一切。不需要终端。”
@_simonsmith 认为（6 个赞、224 次浏览、4 次收藏）认为，Codex Creative Production 插件在制作情绪板时过度设计。配图展示了他提出的替代方案：将 6 张低保真 GPT Image 2 输出排在一个简单的 HTML 网格中；他称，这比当前严重依赖本地服务器的流程更快。
@Adidotdev 发帖称（6 个赞、3 条回复、63 次浏览）指出，Codex 推出 Sites 的同时，Codex 本身也出现了降级。状态截图显示 ChatGPT 和 Codex 的错误率升高，使发布时的兴奋迅速转化为对可靠性的质疑。
讨论洞察： 反对意见并不是认为 Codex 应该继续只做编程工具，而是认为新的角色化工作流需要更快的批量操作、更简单的编辑界面，以及比首批实现所展现出的更可靠的发布质量。
与前一天对比： 6 月 2 日围绕插件和 Sites 的讨论以公告为主。6 月 3 日则出现了具体的企业和电商构建案例，同时也出现了对这些新界面“上线过于仓促”的当日批评。
1.3 成本治理成为 AI 编程产品栈的一部分 🡕¶
当天最强烈的商业讨论围绕成本控制、额度和路由层展开，而不是模型本身的能力。六条保留内容支撑了这一主题。
@GHchangelog 宣布（19 个赞、4 条回复、1,877 次浏览）指出，GPT-4.1 已在所有 GitHub Copilot 使用场景中弃用。关联的 GitHub 更新日志 推荐改用 GPT-5.5，并称 Copilot Enterprise 管理员可能需要通过模型策略将其开放给用户，这使模型选择从个人偏好变成了治理问题。
@tekbog 抱怨（33 个赞、6 条回复、940 次浏览）称，由于 token 定价上涨，Copilot 已经“完全没有理由”继续使用。有人回复说，老用户仍保留旧系统，但额度更少、实际成本更高，这让抱怨从泛泛不满变成了明确的预算问题。
@acadictive 表示（12 个赞、5 条回复、253 次浏览）称，他们在不到三天内就用完了当月 Copilot token。截图显示 Copilot Pro+ 已使用 100%，同时还配置了额外预算，重置日期被推到 7 月 1 日。
@4ster_light 展示了（1 条回复、33 次浏览）提供了学生档位的另一个预算案例：在一天轻度的 Agent 式编程后，200 个自带 AI credits 已经用掉了 139 个；截图显示其中 $1.38 的使用量来自 GPT-5.4 mini。
@yashgogri1 推出了（27 个赞、1 条回复、143 次浏览）展示了按员工和按使用场景分配、带有支出上限和模型路由的 API keys。仪表盘分别为 proj-data-pipeline、ci-eval-runner、sandbox-yash 和 agent-prod-worker 设置了预算，让这一方案更具体可感。
@F2aldi 分享了（2 个赞、2 条回复、198 次浏览）介绍了 Tokscale 这一跨多种 harness 的成本追踪工具。截图显示 9.1 billion tokens、总支出 $5.11K、单日最佳为 $216.35，并支持筛选 Cursor、Codex CLI、OpenCode、Claude Code 和 Hermes Agent，这正是用户所说自己缺乏的可见性。
讨论洞察： 信息流里不只是有人抱怨价格。围绕价格的新工具层已经开始出现：仪表盘、按 key 分配的预算，以及模型路由，帮助用户从经济上控制 Agent 的使用。
与前一天对比： 6 月 2 日出现了额度焦虑和发布日的价格冲击。6 月 3 日则把这种情绪具体化为额度耗尽截图、重置日期和新的治理产品。
1.4 团队正把 AI 编程正式化为可复用的操作系统，而不是一次性提示词 🡕¶
最后一个主要主题，是将可重复的操作实践系统化：计划、技能、记忆、后台任务，以及针对不同角色选择模型。三条保留内容支撑了这一主题。
@mvanhorn 发布了（73 个赞、12 条回复、8,292 次浏览、107 次收藏）是一篇题为“我知道的每一个 Agentic Engineering 技巧”的帖子，它把计划文件视为机器输入，而不是文档。帖子推荐 /ce-plan、语音输入、4-6 个 cmux 标签页、从 Claude 路由 Codex、保留转录记录、记忆存储，以及把任何重复任务都变成可复用技能。当有人回复问为什么自己不去读计划时，作者的回答是：“会拖慢你。”
@nixxin 记录了（9 个赞、8 条回复、3,460 次浏览、9 次收藏）介绍了用 Hermes 在 Raspberry Pi 上构建一个月的经历，包括 Honcho memory、Tailscale、WhatsApp 和 Telegram、OpenRouter 与 OpenAI 访问、用 Gemini 提取记忆，以及针对不同 Agent 角色使用不同模型。有人回复解释说，WhatsApp 集成会把选定的 WhatsApp Web SQLite 交互记录读入 Agent memory，使这一技术栈比泛泛而谈的“我做了一个 Agent”更具体。
@kitlangton 表示（18 个赞、2 条回复、487 次浏览、7 次收藏）指出，OpenCode 已经可以启动后台子 Agent，而一个新的 PR 将允许同步任务也转到后台。后续回复指向 terminal-control，显示出 Demo 背后正在形成的模式：Agent 越来越多地被串联起来，以操作终端、后台任务，甚至其他 Agent。
讨论洞察： 人们如今正在围绕 AI 编程把控制平面标准化——计划、记忆、转录、标签页和后台执行——而不是把每次会话都当成一场全新的聊天。
与前一天对比： 6 月 2 日强调桌面路由器和管理器式产品。6 月 3 日则展示了个人如何把同样的理念组装成自己的 AI 工作操作系统。
2. 大家感到不满的地方¶
按量计费的额度如今像一个不断移动的目标¶
严重程度：高。@GHchangelog 宣布（19 个赞、4 条回复、1,877 次浏览）涉及 Copilot 弃用 GPT-4.1；@tekbog 抱怨（33 个赞、6 条回复、940 次浏览）称 token 定价上涨已经让继续使用 Copilot 失去理由；@acadictive 表示（12 个赞、5 条回复、253 次浏览）称他们在不到三天内耗尽了当月 Copilot 额度；@4ster_light 展示了（1 条回复、33 次浏览）则显示，一个学生档位账户在一天轻度 Agent 使用后已经只剩 61 个 credits。用户正在通过增加明确的控制层来应对，例如 @yashgogri1 正在推出（27 个赞、1 条回复、143 次浏览）展示的按 key 分配预算和路由，以及 @F2aldi 正在分享（2 个赞、2 条回复、198 次浏览）展示的 Tokscale 遥测能力。这一方向值得投入，因为抱怨已经变得现实而紧迫，而不是理论上的担忧。
新的角色化界面仍伴随着本可避免的可靠性和体验问题¶
严重程度：高。@Adidotdev 发帖称（6 个赞、3 条回复、63 次浏览）指出，Codex Sites 在 Codex 降级期间上线，截图显示 Codex 和 ChatGPT 的错误率都在升高。@_simonsmith 认为（6 个赞、224 次浏览、4 次收藏）认为，Creative Production 插件过度设计，因为简单的 HTML 页面加上低质量的批量图像生成，就能更快实现可用的情绪板工作流。@Nikitont 总结了（12 个赞、3 条回复、123 次浏览、5 次收藏）涉及更大范围的插件、Sites 和注释功能发布，使这些毛边问题不再只是一次性的 bug。用户正在通过缩小范围、用更简单的组合绕开官方插件流程，以及确保 Agent 工作可审查来应对。这一方向值得投入，因为瓶颈在于工作流耗时和信任，而不是视觉上的精致度。
Agent 仍在掩盖质量债，而不是消除它¶
严重程度：高。@Pragmatic_Eng 引用了（1 个赞、1 条回复、143 次浏览）中，Dax Raad 谈到 AI Agent 会在代码中埋下“地雷”，让工程师失去平时对“某个捷径有风险”的直觉；@AIHighlight 分享了（9 个赞、824 次浏览）则总结了 Carnegie Mellon 的 TheAgentCompany 基准测试，显示即使是受测表现最强的 Agent，也只能自主完成约 30% 的任务。公开的 Flutter Antigravity 文档 推荐以审查为驱动的开发，与同一种应对模式相呼应：让人工审批环节保持可见，因为输出量并不等于工作可信。这一方向值得投入，因为今天的问题不是 Agent 每次都会失败，而是它们可能一边压低人类本会察觉到的警示信号，一边生成看似合理的输出。
3. 大家希望出现什么¶
具备预算意识的访问控制和路由¶
人们需要的并不只是抽象意义上更便宜的 AI，而是明确的负责人、硬性上限，以及自动将任务路由给既能完成工作又最便宜的模型。@yashgogri1 推出了（27 个赞、1 条回复、143 次浏览）展示了按员工和使用场景分配、带支出上限的 API keys；@F2aldi 分享了（2 个赞、2 条回复、198 次浏览）则通过 Tokscale，让多个编程 harness 中的 token 消耗变得可见。@acadictive 他们在几天内就把 Copilot 用完了（12 个赞、5 条回复、253 次浏览）和 @4ster_light 一个学生档账号的额度已经降至 61 点（1 条回复、33 次浏览）中的抱怨说明了这种需求为何紧迫：人们往往还没觉得自己完成了多少真正的工作，就已经触及上限。机会：直接。
在 IDE、管理器和子 Agent 之间共享状态¶
针对 @kevinhou22 询问（255 个赞、45 条回复、14,884 次浏览、97 次收藏）的回复，要求实现 Antigravity IDE 与 Agent Manager 之间的对话同步，并由更强的监督模型调度更便宜的子 Agent，将一条产品讨论转化成了明确的未满足需求。@mvanhorn 在实际中（73 个赞、12 条回复、8,292 次浏览、107 次收藏）和 @nixxin 在实际中（9 个赞、8 条回复、3,460 次浏览、9 次收藏）所描述的技术栈说明了原因：计划、执行、记忆和消息传递已经分散在多个界面中。机会：直接且有竞争性。
以审查为先、支持精细操作的编辑界面¶
人们希望查看和修改 Agent 输出中的小部分，而不是重新运行整个工作流。@_simonsmith 认为（6 个赞、224 次浏览、4 次收藏）指出，Codex 的 Creative Production 插件应依靠低质量批量生成和简单 HTML 页面，而不是更重的本地服务器流程；公开的 Flutter Antigravity 文档 则出于同样原因推荐以审查为驱动的开发和 Agent 式热重载。这是现实需求，而非理想化诉求：用户要的不是更多生成，而是更安全的迭代。机会：直接。
面向日常工作任务的基准测试和护栏¶
围绕质量的讨论不断要求能够衡量真实工作、捕捉隐性失败模式的系统。@AIHighlight 总结了（9 个赞、824 次浏览）将 TheAgentCompany 作为证据，说明当前 Agent 距离完全自主仍相去甚远；@Pragmatic_Eng 引用了（1 个赞、1 条回复、143 次浏览）则是 Dax Raad 关于 Agent 会把危险捷径掩盖到后续阶段的讨论。需求很实际：团队希望在质量悄然下滑并影响生产或维护之前，就能把它捕捉到。机会：直接。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| Google Antigravity 2.0 + Flutter | Agent 管理器 / 应用工作流 | (+/-) | 以 Agent 为先的界面、以审查为驱动的开发、MCP 支持、Agent 式热重载，以及有文档支撑的 Flutter 流程 | 用户仍在要求 IDE 与管理器同步，以及混合模型的子 Agent 控制 |
| PDBe MCP Servers | MCP 集成 | (+) | 提供可移植的领域工具，并明确给出 Antigravity 和 Codex 配置示例 | 局限于结构生物学工作流，且仍需配置 |
Compound Engineering（/ce-plan、cmux、skills） |
工作流方法 | (+) | 将计划转化为可复用的协调产物，并支持并行标签页、语音、路由和技能 | 更偏向高阶用户，且用户若跳过权限设置，默认做法存在风险 |
| Hermes + Honcho memory stack | 自托管 Agent 技术栈 | (+/-) | 持久化 Agent、按角色选择模型、消息集成，以及 Raspberry Pi 部署 | 配置繁琐，需要反复试验模型和 token |
| OpenCode | 开放式 Agent harness | (+/-) | 后台子 Agent、可改造的控制界面，以及终端自动化 | 质量参差不齐，用户讨论的仍是 PR 和毛边问题，而不是成熟打磨后的体验 |
| Codex plugins / Sites / annotations | 插件 / 应用构建界面 | (+/-) | 将 Codex 扩展到内部应用、电商、情绪板和精细编辑 | Sites 上线时发生降级，加上插件体验方面的抱怨，削弱了信任 |
| GitHub Copilot model policies + AI credits | IDE / 模型访问层 | (-) | 覆盖面广、提供模型选择器和企业策略控制 | GPT-4.1 弃用、额度快速消耗，以及围绕重置日期的预算管理主导了整体情绪 |
| Merge Gateway | 路由 / 治理 | (+) | 提供按用户和使用场景分配的预算，以及按最低适配成本路由模型 | 团队需要采用并维护另一层控制机制 |
| Tokscale | 成本遥测 | (+) | 跨多种 harness 展示 token、支出、连续使用天数，以及单日最高或最低支出 | 只能提供可观测性；它能解释支出，但不会自行降低支出 |
总体情绪偏务实，而非忠诚。@mvanhorn 展示了（73 个赞、12 条回复、8,292 次浏览、107 次收藏）显示，高阶用户愿意在多个工具之间混用计划、语音、路由和记忆；@nixxin 展示了（9 个赞、8 条回复、3,460 次浏览、9 次收藏）则在自托管技术栈中展现了同样的模式。@tekbog 抱怨（33 个赞、6 条回复、940 次浏览）和 @acadictive 报告（12 个赞、5 条回复、253 次浏览）所反映的成本反弹与额度快速耗尽，解释了为什么 @yashgogri1 正在推出（27 个赞、1 条回复、143 次浏览）Merge Gateway 以及 @F2aldi 正在分享（2 个赞、2 条回复、198 次浏览）Tokscale 这样的治理层会如此清晰地获得关注。迁移模式是：在一个界面里做计划，在另一个界面里执行长时间任务，通过 MCP 实现可移植性，并在上层加入明确的预算可见性。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Merge Gateway per-key budgets | @yashgogri1 | 创建按员工和使用场景分配、带支出上限和模型路由的 API keys | 团队看不见谁在消耗 Agent 预算，也不知道每项任务应由哪个模型处理 | Gateway、Anthropic/OpenAI 路由、编程 Agent 集成 | 已发布 | 推文（27 个赞、1 条回复、143 次浏览） |
| PDBe MCP Servers | @PDBeurope | 将 PDBe API 和搜索功能作为 MCP 工具提供给 AI 客户端 | 领域工作流需要在 Agent 界面中直接访问数据，而不是手动复制粘贴 | Python、uvx、MCP、PDBe API/Search、可选 Neo4j graph | 已发布 | 推文（6 个赞、1 条回复、711 次浏览、9 次收藏） / 仓库 |
| Cisco App Builder | @CiscoAI | 让客户和合作伙伴借助 Codex 在 Cisco Cloud Control 中构建定制应用 | 难以快速针对特定企业环境定制内部应用 | Codex、Cisco Cloud Control | Beta | 推文（27 个赞、1 条回复、69,230 次浏览） |
| Wix Headless motorcycle shop | @IShmool | 构建和管理电商网站，包括产品、AI 图片、内容、结账和 CRM | 小团队希望在不依赖终端的工作流中部署店面 | Codex 插件、Wix Stores、Wix Blog API、AI 图像生成、结账、CRM | 已发布 | 推文（4 个赞、2 条回复、104 次浏览） |
| Tokscale | @F2aldi | 跨多个 Agent harness 追踪 token 使用量和成本 | 开发者无法判断日常 AI 工作流的实际成本 | Dashboard、Cursor、Codex CLI、OpenCode、Claude Code、Hermes Agent | 已发布 | 推文（2 个赞、2 条回复、198 次浏览） |
@yashgogri1 推出了（27 个赞、1 条回复、143 次浏览）将 Merge Gateway 作为预算与路由层，@F2aldi 展示了（2 个赞、2 条回复、198 次浏览）则将 Tokscale 作为配套的遥测层。模式十分清晰：按量计费的编程 Agent 制造了治理缺口，构建者正在填补这一缺口，在模型 API 本身之上增加所有权、限制和成本可见性。
第二种构建模式是保留领域或控制平面，把 Agent 嵌入其中。@CiscoAI 展示了（27 个赞、1 条回复、69,230 次浏览）展示了 Cisco Cloud Control 中的 Codex；@IShmool 展示了（4 个赞、2 条回复、104 次浏览）展示了 Wix Headless 店面工作流中的 Codex；@PDBeurope 展示了（6 个赞、1 条回复、711 次浏览、9 次收藏）则展示了通过 MCP 将 PDBe 数据访问引入 Antigravity 和 Codex。反复出现的触发因素不是泛泛的 AI 热情，而是缩短从现有工作流到可用交付成果之间的路径。
6. 新动态与值得关注的内容¶
TheAgentCompany 为可靠性鸿沟给出了数字¶
@AIHighlight 分享了（9 个赞、824 次浏览）总结了 Carnegie Mellon 的 TheAgentCompany 基准测试；随附论文摘要称，受测中最具竞争力的 Agent，在模拟软件公司中只能自主完成约 30% 的任务。值得关注的不只是这个数字，还在于摘要指出，日常浏览、编程、程序执行和与同事沟通仍远未解决，同时还公开发布了代码、数据、环境和评估结果。
Tokscale 让新 Agent 技术栈中的 token 消耗变得清晰可见¶
@F2aldi 分享了（2 个赞、2 条回复、198 次浏览）介绍了 Tokscale；仪表盘截图显示 9.1 billion tokens、$5.11K 总支出、$216.35 的单日最佳、129 个活跃日，并支持筛选 Cursor、Codex CLI、OpenCode、Claude Code 和 Hermes Agent。它的重要性在于，它把“AI 编程变贵了”从一种情绪转化成了可衡量的运营问题，团队可以据此进行比较、预算和优化。
7. 机会在哪里¶
[+++] 具备预算意识的 Agent 网关 - 第 1、2、4 和 5 节的证据都指向同一个缺失层：Copilot 额度耗尽、从 GPT-4.1 到 GPT-5.5 的策略转变、Merge Gateway 和 Tokscale，都表明原始模型访问如今需要配套的所有权、路由和硬性预算控制。
[+++] Review-first quality control for agent output - Evidence from sections 1, 2, 3, and 6 was unusually consistent. Flutter docs recommend Review-driven development, @_simonsmith 认为（6 个赞、224 次浏览、4 次收藏）对精细编辑和批量友好型操作的需求，@Pragmatic_Eng 引用了（1 个赞、1 条回复、143 次浏览）中 Dax Raad 对隐性地雷的讨论，以及 @AIHighlight 分享了（9 个赞、824 次浏览）提供的基准测试证据，都表明完全自主仍然相当遥远。
[++] Shared orchestration across surfaces and models - The replies under @kevinhou22 询问（255 个赞、45 条回复、14,884 次浏览、97 次收藏）对同步状态以及不同监督模型或子 Agent 模型的需求，再加上 @mvanhorn 描述了（73 个赞、12 条回复、8,292 次浏览、107 次收藏）和 @nixxin 描述了（9 个赞、8 条回复、3,460 次浏览、9 次收藏）所展示的多界面技术栈，都说明了需求强烈。它之所以只是中等机会，而非最高优先级，只是因为这一领域已经拥挤且变化极快。
[+] 垂直领域协议包和嵌入式应用构建器 - PDBe MCP Servers、Cisco App Builder 和 Wix Headless 商店都展现出相同模式：保留领域或控制平面，再把 Agent 带进去。这一方向正在形成，但尚未被充分验证，因为每个垂直领域仍需建立自己的信任、集成和审查层。
8. 要点¶
- 产品竞争正在上移到编辑器之上。 @kevinhou22 认为（255 个赞、45 条回复、14,884 次浏览、97 次收藏）显示，用户正在跨多个界面管理几十甚至上百个 Agent；Antigravity、Flutter 和 PDBe 的证据也都指向编排与可移植性，而不是编辑器锁定。
- Codex 的扩张是真的，但首批角色化工作流仍需简化并提升可靠性。 @CiscoAI 展示了（27 个赞、1 条回复、69,230 次浏览）展示了 Cisco Cloud Control 中的企业应用构建；@_simonsmith 认为（6 个赞、224 次浏览、4 次收藏）则指出，某个新的 Codex 插件工作流本应大幅简化。
- 定价如今是工作流设计约束，而不只是采购脚注。 @acadictive 表示（12 个赞、5 条回复、253 次浏览）显示，有人几天内就用完了 100% 的 Copilot 预算；@yashgogri1 推出了（27 个赞、1 条回复、143 次浏览）则展示了用于路由和限制支出的控制层。
- 胜出的团队正在围绕模型搭建流程。 @mvanhorn 发布了（73 个赞、12 条回复、8,292 次浏览、107 次收藏）展示了以计划和技能为核心的操作手册；@nixxin 记录了（9 个赞、8 条回复、3,460 次浏览、9 次收藏）则展示了一个带有记忆和消息能力的多模型自托管技术栈。
- 可靠性主张将越来越取决于真实工作基准测试。 @AIHighlight 分享了（9 个赞、824 次浏览）提供的 TheAgentCompany 证据表明，即使是受测表现最强的 Agent，也只能自主完成约 30% 的任务。