Reddit AI Agent - 2026-06-29¶
1. 人们在讨论什么¶
1.1 贴合工作流的自动化持续胜过泛泛的智能体宣传（🡕）¶
今天最强的实践共识是：企业通常愿意为痛苦的交接、混乱的记录和响应速度问题买单，而不是单纯为一种新的“智能体式”界面付费。多个咨询和代理机构相关讨论都得出了相同结论：让工作流留在用户已经使用的渠道中，只在输入确实混乱的地方加入模型判断。
u/Due-Guard221 在 我靠搭建自动化项目赚了大约 2 万多美元，而我学到的最重要一点是：大多数人卖 AI 的方式完全错了！（54 分，17 条评论）中指出，团队通常不需要新的聊天机器人或仪表盘；他们需要的是 PDF 转提案草稿、CRM 清理，以及嵌入电子邮件、WhatsApp、电子表格和电话工作流中的上下文拼接——这些都是他们已经信任的工具。在评论中，u/Sad-Slide9083（4 分）将其归纳为一份运营清单：找出痛苦的交接环节，衡量错误输出的代价，让第一版以人工审核为先，并明确上线后由谁负责处理故障。
u/Warm-Reaction-456 在 我靠打造 AI 自动化项目赚了 10 万多美元，我来告诉你什么值得做，什么纯属浪费钱（30 分，38 条评论）中也明确划出了同样的边界。原帖作者说，客户问答智能体在告诉买家“订单延迟”而实际并未延迟之前，看起来一直没问题；这件事足以让创始人在六周后叫停项目。同一篇帖子还认为，线索跟进和内部报告值得做，因为它们成本更低、速度更快，也更容易限定边界。u/Common_Dream9420（1 分）进一步点明了这条教训：真正的筛选标准是错误成本，而不是能否把项目包装成 AI。
u/pranav_mahaveer 在 我运营一家 AI 自动化代理机构已经 3 年多了。刚开始时，有件事没人会告诉你。（40 分，16 条评论）中补充了运营方的视角：客户口中的“简单”流程，往往藏着经验性知识、格式错误的 PDF，以及足以击穿整洁演示的糟糕真实数据。u/Sad-Slide9083（1 分）回应称，第一项交付物往往应该是流程图，加上一套基于真实边缘案例的回放测试集，而不是自动化本身。
讨论洞察： 反复出现的观点并不是反对智能体，而是认为：只有在有人定义好稳定的流程边界、审核节点和错误预算之后，模型才真正值得投入。
与前一天相比： 这一主题较 2026-06-28 更受关注。昨天的报告已经倾向于枯燥但可靠的工作流，而不是华而不实的智能体；今天，同一原则出现在更多面向业务的讨论中，对行为改变、定制化部署和错误输出成本的警告也更加明确。
1.2 循环式炒作遭遇更强烈反弹，焦点集中在成本、漂移和确定性上（🡕）¶
第二组高信号讨论集中反对开放式的自主循环。Reddit 用户并不是认为编码智能体毫无用处，而是认为：长时间运行、递归重试和“循环工程”式说法，都需要明确边界、新鲜上下文，以及围绕它们设置的确定性检查。
u/Evening-Plan-7956 在 loop engineering 这股趋势简直是一场财务噩梦（132 分，98 条评论）中集中体现了这种反弹，警告递归编码循环一旦开始把完整的终端日志和聊天记录重新输入模型，就可能迅速烧掉海量 token 预算。随附图片很关键，因为它准确捕捉了引发这场讨论的那句挑衅性说法——“你应该设计能够提示你的智能体的循环”。
u/Future_AGI 在 会话时间越长，你的 agent 就会变得越笨（5 分，18 条评论）中描述了会话后期的失效模式：同一个模型在早期步骤中表现良好，但当上下文窗口被原始历史记录和过大的工具输出填满后，就开始重复调用工具、丢失指令，并不断叠加自身的推理。u/alexbuildswithai（2 分）回应称，解决办法是将真实状态保存在聊天之外，只把智能体实际需要的下一步信息切片传进去。
u/Sufficient_Ninja_821 在 让 agent 尽可能具备确定性的最佳尝试。（5 分，28 条评论）中询问，人们能在多大程度上实现确定性的智能体行为。最具体的回复并没有承诺模型本身可以确定性运行，而是建议设置确定性的边界：固定工具 schema、明确的状态机、黄金轨迹、重试预算和恢复测试。与此同时，u/Bladerunner_7_ 在 我们是不是过于关注模型，而对 agent 基础设施关注不够？（16 分，18 条评论）中询问，真正的瓶颈是否已经从模型转移到了基础设施；讨论大体认同，内存、重试、可观测性和供应商波动才是生产环境故障真正集中的地方。
讨论洞察： 普遍答案是把可靠性工作移出模型：总结已经稳定下来的对话轮次，裁剪工具输出，将状态保存在外部，并让 harness 负责重试、预算和审批。
与前一天相比： 这一主题较 2026-06-28 进一步增强。昨天的报告已经聚焦验证器和评测；今天，讨论进一步扩展到 token 消耗的经济性、上下文窗口漂移，以及“好的 harness”比再次升级模型更重要的日益普遍的认识。
1.3 构建者持续推出控制平面、文件原生知识系统和编码 harness（🡕）¶
今天构建者活动最活跃的领域，是那些让智能体工作过程可检查的产品形态。相比通用型副驾驶，最具体的成果是控制中心、代码仓库原生知识系统、网关和编码编排器，它们公开呈现状态、审批节点、轨迹和隔离执行环境。
u/ageniusai 分享了 我把一个用于管理多个 n8n 实例的自托管“指挥中心”开源了。正在招募测试者。（23 分，10 条评论），这是一个用于管理多个 n8n 实例的开源控制中心。公开的 AgeniusDesk CE README 显示，它为所有实例提供统一仪表盘、实时错误流、单次执行轨迹、token 支出跟踪、密钥管理，以及可选的智能体集群支持；截图还展示了同一界面中的研究区、代码实验室、模型和实例控制功能。
在 你构建过的最强 agent 是什么？（42 分，37 条评论）中，u/Jet_Xu（1 分）提到了 DocMason。其 README 将其描述为一个代码仓库原生应用，用于围绕私有工作文件构建本地、可追踪的知识库。图片很有信息量，因为它展示了完整架构：源文档、准备/同步阶段、已发布的知识库，以及带有 grounded-composition 和轨迹产物的智能体运行时。
u/liviux 在 我围绕 LLM councils、worktrees 和 fresh-context retries 构建了一个本地 AI 编码编排器（完全开源）（3 分，7 条评论）中表达了类似的“将状态保存在聊天之外”的思路。这是一个开源编码编排器，会将工作拆分成较小的 bead，在各自的 git worktree 中运行，并以全新上下文重试失败任务。公开的 LoopTroop README 确认其支持 LLM-council 规划、隔离的 bead 执行、Ralph 风格重试和人工审批闸门；生命周期图片清晰展示了这一结构。
讨论洞察： 即使构建者使用了前沿模型，产品主张也很少是“模型很聪明”。更常见的说法是：“系统会留下痕迹、隔离工作、让状态可见，并允许人工检查发生了什么。”
与前一天相比： 这一主题较 2026-06-28 更受关注。昨天构建者的热情主要集中在 n8n 运维和工作流修复上；今天则扩展到了代码仓库原生研究系统、编码智能体编排，以及围绕外部集成构建的可复用网关。
2. 人们感到不满的地方¶
无止境的循环浪费 token，并且会随时间推移而退化¶
严重程度高。u/Evening-Plan-7956 表示，loop engineering 这股趋势简直是一场财务噩梦（132 分，98 条评论）中的一个边界设置糟糕的编码循环，可能不断重新注入聊天记录和终端日志，直到系统“制造出一张巨额 API 账单”。u/Future_AGI 在 会话时间越长，你的 agent 就会变得越笨（5 分，18 条评论）中从另一个角度描述了同样的可靠性问题：长任务大约进行十步后，智能体便开始重复调用工具、丢失早先的指令，并淹没在转录噪声中。在 让 agent 尽可能具备确定性的最佳尝试。（5 分，28 条评论）中，评论者表示，“确定性”唯一可行的定义，是围绕非确定性模型建立确定性边界——固定 schema、明确的状态机、最大重试次数、支出上限和恢复测试。目前的应对方式是总结旧对话轮次、裁剪工具输出，并将状态移出聊天。这一问题仍值得投入，因为相关抱怨具体、反复出现，而且与真实成本直接相关。
现实流程的混乱持续击穿整洁的演示¶
严重程度高。u/Due-Guard221 在 我靠搭建自动化项目赚了大约 2 万多美元，而我学到的最重要一点是：大多数人卖 AI 的方式完全错了！（54 分，17 条评论）中表示，许多企业其实并不需要 AI 智能体；他们需要的是在现有工具中修复电子邮件收件箱、CRM、电子表格、PDF 和电话工作流。u/pranav_mahaveer 在 我运营一家 AI 自动化代理机构已经 3 年多了。刚开始时，有件事没人会告诉你。（40 分，16 条评论）中补充说，客户口中的“简单”流程经常隐藏着经验性知识、例外情况和脏乱的真实数据；而 u/Warm-Reaction-456 在 我靠打造 AI 自动化项目赚了 10 万多美元，我来告诉你什么值得做，什么纯属浪费钱（30 分，38 条评论）中表示，如果错误恰好发生在那 20% 的部分，即使一个面向客户的智能体有 80% 的正确率，也可能代价过高。普遍的应对方式，是花更多时间观察真实操作人员、收集糟糕但真实的案例，并让第一版以人工审核为先。这使该问题具有重要的商业意义：人们一次又一次付费去发现同一个范围界定错误。
一旦智能体接触线上系统，生产控制仍然过于薄弱¶
严重程度高。u/NowHaraya 在 agent 评测延迟让我们的 CI 多了 18 分钟。你们是怎么在不拖垮开发速度的前提下跑这个的？（17 分，14 条评论）中报告称，一个阻断式评测闸门将 CI 的 p99 时间从 6 分钟推高到 24 分钟，导致工程师改为批量提交变更，而不是持续发布。u/Common_Dream9420 在 AI agents 采取了一个未经我批准的真实世界操作。以下是我为解决这个问题正在构建的东西。（7 分，17 条评论）中表示，一个供应商外联智能体差点因为 CRM 数据过时，把合同修订发送给错误的联系人；讨论最终认为，外部审批队列、新鲜度检查、留痕，以及影响半径限制是解决办法。u/percoAi 在 当 AI agents 从演示走向生产环境时，究竟会出什么问题？（5 分，22 条评论）中进一步提出同样的担忧：演示只能证明智能体能够完成一次任务；生产系统还需要幂等键、审批历史、重试策略，以及人类可读的运维可解释性。当前的应对方式是定制闸门、暂存表、影子模式和人工审批，这表明控制平面仍未得到充分建设。
3. 人们希望存在的东西¶
人工可审计、且智能体真正能够写入的记忆¶
这是数据集中最明确的诉求之一。在 对 agent 而言，可供人工审计的记忆是我的故障点（6 分，10 条评论）中，u/cheetosarered 表示，当智能体无法将角色专属笔记或合同偏好记忆追加到一个可审计、可供操作人员检查的位置时，ChatGPT 和 Gemini 的配置都会崩溃。这个需求很实际，而非理想化：用户已经清楚知道自己要什么——可写入的记忆、可见的记录，以及适合企业使用的权限。它还带有明显的情绪色彩，因为令人沮丧的不是模型质量，而是某种能力在执行时消失，仿佛此前只是被承诺过。机会：直接。
像真实用户一样运行、并能自我维护的评测¶
多个讨论都指向同一缺口。u/gojosoju 在 这个 agent 在开发环境中运行良好，但面对真实用户的表达方式就会失败。你们是如何弥合这个差距的？（17 分，9 条评论）中报告称，开发者编写的查询准确率约为 94%，而真实用户措辞下的准确率约为 71%；与此同时，u/Only_Midnight_8557 在 我们大约有 340 个评测场景，其中约 80 个从来没标记出任何问题。你们是怎么精简评测集的？（17 分，12 条评论）中表示，340 个评测场景中约有 80 个在六个月内从未触发任何问题，另有 40 个场景持续捕捉同一种故障模式。在 CI 讨论中，u/NowHaraya 和评论者希望采用更小的阻断式冒烟测试集、按变更区域触发闸门，以及提升生产轨迹，而不是每次提交都为每个场景支付完整成本（agent 评测延迟让我们的 CI 多了 18 分钟。你们是怎么在不拖垮开发速度的前提下跑这个的？）（17 分，14 条评论）。这是一个实际需求，用户已经勾勒出了清晰的工作流。机会：直接。
能预览操作、要求审批并留下痕迹的控制平面¶
人们反复提出的平台愿望，并不是“更好的聊天界面”。在 描述一下你理想中的 AI 平台（5 分，32 条评论）中，评论者表示，他们理想中的平台应该知道自己能够触碰哪些系统，预览高风险写入，在适当节点请求审批，并留下重试或回滚状态。u/Common_Dream9420 在 AI agents 采取了一个未经我批准的真实世界操作。以下是我为解决这个问题正在构建的东西。（7 分，17 条评论）中将同一要求具体化：针对过时 CRM 数据导致的外联问题，解决方案应包括新鲜度检查、痕迹包、明确的收件人预览，以及将审批与最终发送分开记录。现有构建者已经在尝试通过 AgeniusDesk CE、LoopTroop 和 AgentSpan 等项目回应这一需求，因此这一机会并非空白，竞争已经存在。机会：竞争型。
面向智能体和工作流的共享集成层¶
u/Fearless-Role-2707 在 我已经厌倦了在每个 n8n AI 工作流里反复重建同样的集成（12 分，6 条评论）中表示，每个 n8n 工作流都在反复重建 HTTP 节点、凭据、重试和 API 专属逻辑，这促成了 AgentSpan——一个位于多个服务前方的统一网关。公开的 AgentSpan README 进一步扩展了这一主张，提供自托管 Rust 网关、MCP 服务器、SDK、缓存和多个平台连接器。对于已经感受到集成成本的构建者而言，这是一个实际需求；但它比审批/控制平面需求更窄，因为主要面向高级用户和运营人员。机会：竞争型。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| n8n | 工作流自动化 | (+) | 触发器、分支、重试和面向操作人员的工作流清晰可见；今天许多具体项目都以它为核心 | 需要明确的幂等保护、审批设计和更强的生产控制 |
| OpenAI models / Chat Model nodes | LLM | (+/-) | 在多个工作流中用于分类、聊天、规划和客户互动 | 面向客户的路径一旦产生错误输出，代价高到足以让部署被叫停 |
| Airtable | CRM / 结构化存储 | (+/-) | 适合记录 welcome sent、visit status、follow-up date 和 property media 等明确的线索字段 | 智能体基于过时记录采取行动时，数据陈旧会直接构成安全风险 |
| Supabase | 数据库 / 身份验证后端 | (+) | 适合健身房签到 MVP 和实时订阅检查的轻量后端 | 评论者仍质疑整个工作流是否足以应对生产环境的延迟和故障处理 |
| Google Sheets | 轻量运营存储 | (+/-) | 适合日志记录和快速原型 | 多次被批评对于严肃的生产工作流而言过慢或过于脆弱 |
| Git worktrees | 开发方法 | (+) | 隔离编码智能体的工作、保持主检出目录整洁，并让重试更安全 | 工作区隔离并不等于安全沙箱 |
| Human approval gates | 治理方法 | (+) | 广泛适用于外发消息、生产写入和高风险状态转换 | 会降低吞吐量，而且必须有清晰的留痕设计才有用 |
| Gateways / harnesses / control planes | 基础设施方法 | (+) | 减少重复的集成工作，将状态保存在聊天之外，公开轨迹并限制重试 | 增加系统复杂度，目前仍由实践者以零散方式逐步构建 |
当技术栈让控制面更清晰，而不是假装自主性可以消除工程需求时，整体满意度最高。反复出现的方法是：让模型解释混乱的输入，然后在任何高成本或外部操作发生之前，将任务交给确定性的状态检查、类型化输出、审批闸门或有边界的工作流。
最明显的迁移方向，是从“一段很长的智能体聊天”转向带 harness 的系统：用 git worktrees 取代混乱的会话，用外部状态取代完整的转录回放，用控制平面或网关取代在每个流程中手动连接相同的 API。竞争态势也不再只围绕模型原始能力展开；供应商波动、价格变化、可追踪性和集成开销同样被视为重要的采购标准。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| Automated Gym Check-in System | u/Charming_You_8285 | 使用二维码 Web 应用和工作流后端验证会员资格并记录入场 | 用更快的会员验证流程取代健身房前台的人工签到 | Next.js PWA、n8n、Supabase、Google Sheets、barcode-scanner node | Alpha | 帖子、仓库、gist |
| AI real estate sales assistant | u/Jazzlike_Power_6197 | 处理线索接入、房源匹配、预约看房、跟进提醒和 CRM 更新 | 为销售团队提供一个边界明确的助手，用于处理重复性的线索筛选和排程 | n8n、OpenAI、Airtable、WhatsApp、Gmail、Google Calendar | Alpha | 帖子、转发帖 |
| AgeniusDesk CE | u/ageniusai | 集中管理多个 n8n 实例，提供错误流、轨迹、代码编辑、密钥管理和可选的智能体支持 | 让工作流操作人员能够在一个地方查看自动化集群中哪里出了问题 | Python、Docker、OpenTelemetry、n8n，可选 LangGraph/PydanticAI 支持 | Beta | 帖子、仓库、演示 |
| DocMason | u/Jet_Xu | 将办公文件编译成本地、可追踪的知识库，用于深度研究 | 让私有文件研究比基于扁平文本的普通聊天更容易审计 | 代码仓库原生知识库、Codex/Claude Code 运行时、本地解析流水线 | Alpha | 讨论串、仓库 |
| LoopTroop | u/liviux | 将编码任务转化为 PRD、bead、隔离的 worktree 运行和全新上下文重试 | 让长时间的编码智能体任务可检查、可恢复，而不是依赖一段脆弱的聊天 | 本地 GUI、LLM councils、git worktrees、OpenCode | Alpha | 帖子、仓库 |
| AgentSpan | u/Fearless-Role-2707 | 在智能体和多个外部服务之间设置统一网关 | 从每个工作流中移除重复的 API 连接、凭据、重试和连接器逻辑 | Rust 网关、REST API、MCP 服务器、SDK、仪表盘 | Beta | 帖子、仓库 |
| WhatsApp Priority Message Classifier | u/Intelligent-Play-361 | 将收到的 WhatsApp 消息分为高优先级或低优先级，并路由 Gmail 通知 | 提供一个由初学者构建的、范围狭窄且可检查的消息分流智能体示例 | n8n、OpenAI、Structured Output Parser、Gmail、WhatsApp | Alpha | 帖子、仓库 |
- 阶段 — 项目所处阶段：Shipped（已上线/生产环境）、Beta（可用但尚不完整）、Alpha（早期原型）或 RFC（想法/提案，尚无可运行代码）
- 技术栈 — 项目所采用的语言、框架、模型或服务
- 解决的问题 — 促成该项目的具体痛点或缺口
- 链接 — GitHub 仓库、项目网站、演示、博客文章或项目所在位置
健身房签到系统很好地体现了 Reddit 对具体运维细节的认可。公开 README 证实它采用 Next.js PWA 作为 n8n 工作流的前端；与此同时，评论区对原先 2–6 秒的审批时间提出了足够强烈的质疑，促使原帖作者发布更新后的执行截图，显示运行时间已降至亚秒级和约 700ms。
WhatsApp 分类器的得分较低，但其图片让架构变得可审计：WhatsApp 触发器进入 AI 智能体，再经过结构化输出解析器、条件分支和等待步骤，最后进入两条 Gmail 路径。这正是数据集中其他讨论反复推荐的那类有边界、可检查的智能体设计。
AgeniusDesk CE、DocMason、LoopTroop 和 AgentSpan 都指向同一种更高层次的构建模式：实践者不再只是构建任务型智能体，也在构建围绕智能体运行的操作系统。AgeniusDesk 为工作流集群集中管理错误流和轨迹；DocMason 将本地文件转化为受治理的证据层；LoopTroop 将长时间的编码工作拆分成可审核的 bead，并支持全新上下文重试；AgentSpan 则将重复的服务集成收拢到一个网关中。
房地产助手和 WhatsApp 分类器展示了同一光谱中更窄的一端。两者都将范围限定在一条重复性的沟通流程上，尽可能使用结构化字段而不是自由格式记忆，并让操作人员清楚看到工作流在哪些位置发生分支。反复出现的构建模式是：最可信的项目都在模型周围打包控制面，而不是要求模型成为整个产品。
6. 新动态与值得关注的事项¶
对供应商的依赖本身已成为明显的风险信号¶
u/shanjairaj_2000 使用 GPT 5.6 Sol 遭遇了和 Claude Mythos 一样的命运。到底发生了什么？？（102 分，58 条评论）主张，完全依赖前沿模型 API 的团队会暴露在访问限制、价格变化和路线图不稳定等风险下。即便反对原帖作者具体观点的评论者，也认同一个更窄的结论：供应商依赖是一种负担，本地模型或开放模型的备用方案正越来越被视为一种韧性策略，而不只是意识形态选择。
开源构建者正在把智能体基础设施变成公开产物，而不只是演示¶
最强的构建者帖子并不是模糊的展示。DocMason、LoopTroop、AgeniusDesk CE 和 AgentSpan 都发布了公开仓库、截图和文档，展示智能体周围的控制层：文件来源、规划委员会、隔离的 worktree、轨迹、网关和审批界面。这一点值得关注，因为它将讨论从“什么提示词有效？”转向了“围绕模型的哪种操作系统正在变得可复用？”
社区对“理想 AI 平台”的愿望清单，主要关乎治理和连续性，而不是更大的聊天界面¶
在 描述一下你理想中的 AI 平台（5 分，32 条评论）中，信号最强的回复要求结构化记忆、操作预览、审批闸门、留痕、回滚状态，以及一个能够区分规范内容、草稿、决策和未完成任务的项目大脑。这与 对 agent 而言，可供人工审计的记忆是我的故障点（6 分，10 条评论）高度呼应；后者提出的未满足需求，是一种能够写入可审计记忆界面的智能体，而不是将状态困在黑箱中。
7. 机会在哪里¶
[+++] 以审批优先的行动型智能体控制平面 — 证据来自过时 CRM 数据导致的供应商外联险情、生产控制平面讨论、理想平台愿望清单，以及 AgeniusDesk 和 LoopTroop 等构建者项目。最强需求是构建这样的系统：预览操作、验证数据新鲜度、在适当边界要求审批，并留下痕迹、回滚状态和审计日志。
[+++] 现有渠道内、贴合工作流的自动化 — 多个高参与度讨论认为，真正的价值仍在于修复电子邮件、WhatsApp、CRM、电子表格和 PDF 中痛苦的交接，而不是销售一个通用智能体外壳。这个信号很强，因为同一模式同时出现在咨询建议、代理机构复盘，以及房地产助手、健身房签到流程和 WhatsApp 分类器等具体项目中。
[++] 评测路由与场景管理工具 — CI 延迟、过时场景和真实用户措辞等讨论都指向同一需求：更小的阻断式测试集、按变更区域触发闸门、提升生产轨迹，以及更好地清理长期休眠的场景。这是一个中等机会，因为问题明确且紧迫，但买方范围比更广泛的控制平面市场更窄。
[+] 共享网关与外部状态 harness — AgentSpan、LoopTroop 和关于上下文漂移的讨论都主张将状态保存在聊天之外，并减少重复的服务连接工作。这个信号正在形成，尚未占据主导，但在构建者仓库和运维层面的抱怨中都保持一致。
8. 核心结论¶
- 今天 Reddit 上最确定的一条规则仍然是：先让工作流合适，再添加智能体。 获得最多赞的实践讨论表明，价值来自修复团队已经在使用的渠道中的痛苦交接，而不是强行引入一个新的 AI 界面。（来源）
- 人们评价自主循环时，越来越少问“它们能不能编码？”，转而关注成本、漂移和重试行为。 Reddit 上参与度最高的循环讨论，是对无边界递归的反弹；附近的讨论也持续要求外部状态、裁剪后的上下文，以及确定性的 harness 边界。（来源）
- 控制面正逐渐成为独立的产品类别。 AgeniusDesk、DocMason、LoopTroop 和 AgentSpan 都在模型周围封装了轨迹、知识边界、隔离工作区或共享网关，而不是把模型当作整个系统。（来源）
- 现实世界的评测仍然无法充分反映真实情况。 用户报告称，开发者编写的查询与真实用户措辞之间存在 23 个百分点的差距，评测套件也日益臃肿，已不再值得其计算成本。（来源）
- 最明确的未满足需求并不是另一个前沿模型，而是可审计的操作和记忆。 人们希望拥有审批队列、留痕、回滚状态，以及可供检查的可写入记忆，尤其是在机密或企业工作流中。（来源）