Bend2 / AI Agent 问题梳理

来源：Victor Taelin @ X · 作者：Victor Taelin · 日期：2026-05-27

AI Agent 相关问题

  1. 速度太慢 — 不用 agent 的日子反而产出更高，agent 的 thinking paradigm 本身令人反感。
  2. Reward hacking — agent 写出的代码只对测试负责，测试没覆盖的部分靠碰运气。agent 找到的是"恰好能过测试"的方案，而不是正确的方案。（关联 正确方案被绕过、C/Metal 编译器代码质量崩溃）
  3. 正确方案被绕过 — 很多模块最简单的方案就是正确答案，但 agent 仍然选择了更复杂、只对测试有效的写法。（关联 Reward hacking、测试外行为不可预测）
  4. 合并前不读 AI 代码 = 自毁 — 对维护性有害，属于根本性错误。（关联 Reward hacking、正确方案被绕过）
  5. 最佳用途边界 — agent 适合调试、调研、脚本/工具，不适合触碰长期维护的核心代码。

Bend2 项目具体问题

  1. C/Metal 编译器代码质量崩溃 — 作者原话"clusterfuck"，测试全过但 bug 极多。（关联 Reward hacking、正确方案被绕过）
  2. 测试外行为不可预测 — 未覆盖的路径等同于 coin toss。（关联 Reward hacking）
  3. GPU 性能是核心竞争力 — 对手 Lean 非常强，必须有显著差异化才能发布。
  4. 发布前不能有 bug — 项目性质决定了有 bug 会很难看。（关联 测试外行为不可预测）
  5. 时间紧迫 — clock is ticking，10h/天 SupGen，剩余给 Bend2。

元层面的讽刺

  1. Bend 自己的 proof system 本该解决这个问题 — 证明系统就是用来保证代码正确性的，但 proof system 是用 TypeScript 写的而不是 Bend，所以无法自证。（关联 测试外行为不可预测）
  2. 没有自举（self-hosting） — 作者后悔没用 Bend 写 Bend，现在想做但时间不允许。（关联 Bend 自己的 proof system 本该解决这个问题、时间紧迫）

MiniMax 稀疏注意力问题

来源：rameswar08 @ X · 日期：2026-05-27

标准 attention 的根本瓶颈

  1. O(n²) 复杂度 — 每个 token 要看所有其他 token，规模一大速度就不可用。（关联 长上下文计算成本爆炸）
  2. 长上下文计算成本爆炸 — 1M token 的深度处理需要 absurd amounts of GPU power。（关联 O(n²) 复杂度）
  3. 准确性和速度的矛盾 — 全量注意力保证质量但牺牲速度，必须在两者之间找平衡。（关联 用"不看所有内容"换速度）

稀疏注意力的赌注

  1. 用"不看所有内容"换速度 — 先粗扫找相关部分，再只精读那些内容，像查索引。（关联 准确性和速度的矛盾）
  2. 相关性检索的覆盖风险 — 赌的是粗扫能找到真正重要的部分，遗漏的可能性存在。（关联 用"不看所有内容"换速度）
  3. 10x/15x 加速来自跳过不相关 token — 不是优化计算本身，而是减少计算量。

MiMo API 降价问题

来源：_LuoFuli @ X · 日期：2026-05-28

KV 缓存成本问题

  1. 缓存容量瓶颈 — 优化前 KV 缓存容量不足以支撑大规模并发，通过分层 KV 缓存优化才提升 5x。（关联 缓存成本过高）
  2. 缓存成本过高 — 优化前缓存成本占推理成本很大比例，Input (Cache Hit) 降价幅度达 99%，说明原价严重虚高。（关联 缓存容量瓶颈）
  3. Cache Read Overlap 被忽视 — 多个 Full Attention 模块之间的缓存读取重叠可以进一步压低成本，但多数推理框架没有利用这个优化。

行业定价的结构性问题

  1. 盲目降价导致亏损 — 大多数模型架构和推理优化无法支撑低价 API 不亏本运行，MiMo 之前也警告过行业不要盲目降价。
  2. 只有架构级优势才能支撑低价 — MiMo 的 1:7 Full:SWA 稀疏比让 70 层模型的 prefill 计算量约等于 10 层 GQA 模型，这种结构性成本优势在行业中很少见。（关联 盲目降价导致亏损）
  3. 低价驱动的良性循环条件苛刻 — 低价 API → 推理需求增长 → 基础设施链发展 → 成本下降 → 更低价，这个循环的前提是架构本身省算力且推理 Infra 足够好。（关联 用"不看所有内容"换速度）

LLM 实践与认知问题

来源：Nate Berkopec @ X · 作者：Nate Berkopec · 日期：2026-05-28

"AI" 叙事问题

  1. "AI" 是错误的认知框架 — "intelligence" 这个词让人陷入科幻思想实验和"奇点即将到来"的废话，而不是关注 LLM 实际有用的地方。（关联 锯齿状智能越来越锯齿）
  2. 锯齿状智能越来越锯齿 — LLM 能解 Erdős 问题但解不了简单的洗车脑筋急转弯，视觉智能和理解力远不如语言和数学能力。（关联 "AI" 是错误的认知框架）
  3. 进步是线性的不是指数的 — 只有一个 benchmark 图显示指数进步，其余所有合成 benchmark 和主观体验都是稳定线性进步。

LLM 使用的实际问题

  1. 程序员整天在 babysit LLM — 在 Claude 里输入，等 15 秒，再输入，周而复始。这真的是我们能做的最好的吗。（关联 速度太慢）
  2. 自动补全的自我退化 — 接受不完美的输出后，它成为下一次输入的一部分，拉低后续输出质量。好的 AI 工作流需要频繁通过工具调用注入有用信号。
  3. 没有"好的"潜在空间 — 无法通过 prompt 把 LLM 从"普通程序员"空间拉到"像 Dijkstra 编程"空间。角色扮演 prompt 不起作用，因为潜在空间中不存在秘密的超智能区域。
  4. LLM token 是有损解压 — 模型权重是人类知识的 TB 级压缩，prompt 是试图找到有用解压，但 token 输出是有损的，而工具调用结果是无损的——它是关于世界的真实信息。

有效的 LLM 工作流特征

  1. 可验证性 — 最终结果越能在客观、可验证的基础上被评判，效果越好。（关联 Reward hacking）
  2. 暴力循环 — AI agent 想要通过尽可能多的循环来应用 bitter lesson，用 token 撞击工具来了解和修改世界状态。有用的 LLM 工作流看起来像暴力尝试。（关联 自动补全的自我退化）
  3. 重复性苦力 — 开发 AI 工作流就是开发软件应用，需要投入时间，因此最好能应用到数百小时的人力工程上，而不是一次性场景。
  4. 原型到结晶 — LLM 擅长在 5 分钟内拼出原型，但如果结果有用，仍需投入人力将其"固化"为真正的软件。（关联 C/Metal 编译器代码质量崩溃）

软件工程的本质未变

  1. 做好软件仍然难 — 部分变容易了，但这意味着其余部分必须做得更好才能在市场中胜出。
  2. 非确定性是新挑战 — LLM 是栈中间的一个新工具，它的非确定性要求新的技术和方法。（关联 测试外行为不可预测）
  3. 制造制造东西的东西 — LLM 让我们能建造软件工厂，重点不是做东西，而是做更高阶的：做制造东西的东西。

Obsidian / Cortex #179 问题梳理

来源：relay.fm/cortex/179 · YouTube：watch · 作者：Myke Hurley（主持）× Steph Ango（Obsidian CEO） · 日期：2026-05-25

插件生态的稳定性问题

  1. 更新后界面崩溃 — 用户下载最新版本后按钮全部消失，原因通常是某个主题期望了某个特定行为。"You can 100% shoot yourself in the foot with that."。（关联 无法穷举测试边缘情况）
  2. 无法穷举测试边缘情况 — 任何人都可以不经许可制作插件和主题，团队不可能覆盖所有组合。（关联 更新后界面崩溃）
  3. 对策是延长 beta 周期 — 每次更新在 catalyst 阶段停留数周到一个月，但依然不能完全避免。

商业模式的结构性困境

  1. 商业许可完全靠自觉 — 公司内两人以上使用需付费 $50/年，但无法强制执行。已知有千人以上公司不付费使用，"left probably millions of dollars on the table"。（关联 最终选择取消强制商业许可）
  2. 无法衡量活跃用户数 — app 内无 analytics，只能通过 GitHub 下载量和应用商店数字粗略估算。（关联 最终选择取消强制商业许可）
  3. 企业账单混乱 — 某母公司旗下 100+ 子公司各自购买商业许可，负责人离职后整个整合项目崩塌。
  4. 最终选择取消强制商业许可 — 反映现实而非理想，但也意味着放弃了可量化的收入。（关联 商业许可完全靠自觉、无法衡量活跃用户数）

AI 双向拉扯

  1. 用户因不想用 AI 而迁移到 Obsidian — 其他工具界面被 AI 功能污染，Obsidian 因"没有内置 AI"反而成为避风港。（关联 用户因想用 AI 而迁移到 Obsidian）
  2. 用户因想用 AI 而迁移到 Obsidian — markdown 文件天然适合 LLM 处理，人们用 Obsidian 查看和交互 AI 生成的内容。（关联 用户因不想用 AI 而迁移到 Obsidian）
  3. 两个方向同时发生且互相矛盾 — 产品定位因此受益，但也带来了身份认同的困惑。

团队协作与无会议模型的代价

  1. 偶尔遗忘事情 — Steph 承认"once in a while that I just totally forget something is happening"。（关联 复杂项目仍需临时会议）
  2. 复杂项目仍需临时会议 — 近期因一个多领域交叉项目不得不开了一次会，说明无会议模型有上限。（关联 偶尔遗忘事情）
  3. 异步沟通的心跳广播 — 团队成员在 Discord 发布状态更新"不是为了让人回复，只是 verbalize what is currently going on"，本质上是 rubber ducking 的制度化。

协作功能的缺失

  1. Obsidian 至今是单人工具 — "very siloed as an app"，连与伴侣共享购物清单这种基本需求都无法满足。（关联 社区长期要求协作能力）
  2. 社区长期要求协作能力 — 这是 roadmap 上的重要方向，但从本地文件到协作的跨越在架构上是根本性的。（关联 Obsidian 至今是单人工具）

翻译与多语言

  1. AI 翻译准确率约 90% — 剩余 10% 需要社区人工修正，但至少解决了从 15 种语言到 40+ 种语言的覆盖问题。（关联 AI 前的翻译状态）
  2. 右到左语言和复杂文字系统 — 阿拉伯语、希伯来语需要界面镜像，高棉语每个字符占 15 倍字节。
  3. AI 前的翻译状态 — 社区手工翻译的 12-15 种语言中，很多页面已过时（如商业许可变更后仍显示旧规则）。（关联 AI 翻译准确率约 90%）

任务管理的反直觉简化

  1. 每周新建一个 to-do list，不看上周的 — 迫使自己重新评估优先级，自然筛选出真正重要的事。（关联 反复 rollover 的任务最终消失）
  2. 反复 rollover 的任务最终消失 — "like emails, sometimes you just got to archive all"。（关联 每周新建一个 to-do list，不看上周的）
  3. 笔记问题 — "I have so many notebooks everywhere"，纸质笔记本的物理堆积是数字迁移的常见动因。

不代理理解（Don't Delegate Understanding）

  1. 核心恐惧 — 如果在每个环节都外包理解，就会"covered in parasites that are making it seem like it's easy"，被提取时间和金钱。（关联 AI 编程的克制）
  2. AI 编程的克制 — Obsidian 团队几乎不在编程中使用 AI，因为想要"really really firm understanding of our code base"。（关联 核心恐惧）
  3. 积极面：caloric energy is precious — 把需要消耗卡路里的认知工作转化为电能完成，但前提是理解你委托的是什么。

Plain text 的赌注

  1. File over app 的核心逻辑 — app 终将消亡（操作系统变化、用户行为变化、输入设备变化），但纯文本自 1960 年代存在至今。（关联 LLM 意外受益）
  2. 对云端数据租用模式的批判 — 过去 15-20 年人们把数据上传到别人服务器，以非加密方式租用自己的数据，"pendulum is swinging away from that"。
  3. LLM 意外受益 — plain text 对 LLM 最友好，但这是 karma 而非设计预判。（关联 File over app 的核心逻辑）

小团队的有意限制

  1. 7 人全职 — 3 工程师 + Erica + Steph + 客服 + 社区负责人。
  2. 不追求规模 — "I don't mind that constraint"，接受 Obsidian 不会成为微软。
  3. 从 45 人创业公司的教训 — Steph 在 Lumi 有 8-10 个会议/天的 "calendar hellscape" 经历，整个 Obsidian 的组织设计是对那段经历的有意识反叛。（关联 TiddlyWiki + CSS hacks 的前身）
  4. TiddlyWiki + CSS hacks 的前身 — Obsidian 之前 Steph 用 TiddlyWiki 加大量 hack 来实现类似功能，说明需求先于产品存在。（关联 从 45 人创业公司的教训）

Rippletide 决策上下文图

来源：https://x.com/rippletide · 日期：2026-05-28

企业 AI 代理失败根因

  1. 企业 AI 代理普遍失败 — 缺乏结构化记忆与决策上下文，易遗忘已学知识、产生累积错误，无法稳定落地。
  2. 学习呈阶段性回归 — 新技能覆盖旧能力，出现 regressive 问题（关联 autocomplete-degradation）。（关联 自动补全的自我退化）
  3. 多步骤任务中误差累积 — 小误差在长链路中累积成灾难性错误（关联 nondeterminism）。（关联 非确定性是新挑战）
  4. 决策不可追溯不可解释 — 无法审计 AI 的推理过程和决策依据。

RAG 架构局限

  1. RAG 只检索语义相关文档 — 无法提供决策上下文，不判断信息时效性、优先级、适用性。
  2. RAG 易引发幻觉与错误决策 — 检索信息与实际决策脱节，无法识别规则过期、冲突、更新。

决策上下文图方案

  1. 适用性原则 — 编码规则逻辑，仅返回当前场景有效的上下文，过滤过期和不适用信息。
  2. 时间感知记忆 — 所有规则、决策、例外均绑定有效期，区分历史与当前有效信息。
  3. 决策路径可追溯 — 可追溯推理过程，解释决策依据，复用历史案例。
  4. 融合神经符号 AI — 神经层保障自主能力，符号层降低数据依赖、提升可控性。
  5. 自动构建本体 — 结构化梳理实体、规则、例外，从杂乱数据中提取结构。

非回归性

  1. 非回归性（Non-regressivity） — 冻结验证通过的行为序列，以稳定成果为基础持续迭代，新学习不覆盖旧能力。
  2. 行动前校验规则 — 杜绝幻觉与违规，保障行为一致、可预测、可审计。

待验证问题

  1. 自动本体生成的稳定性 — 在企业杂乱、多元数据场景下，自动构建本体的准确性和稳定性仍需检验。