AI Agent

两天之内 4700+ Star，241 条 HN 评论——小米 MiMo Code 的发布在开发者社区引起了不小的波澜。但让我真正感兴趣的不是这个数字本身，而是它背后的策略：fork 一个已经有 17 万 Star 的开源项目 OpenCode，然后在上面叠加自己的东西。 坦白说，“大厂 fork 开源项目"这件事本身就自带争议。HN 评论区有人直接开喷：“fork 一个已有的开源项目，不给上游贡献代码，附加可能跟 MIT 许可证冲突的使用限制，然后还要 PR。“但也有另一种声音：如果 fork 出来的东西确实有实质性的技术创新，那这件事本身就有讨论的价值。 所以这篇文章想回答的核心问题是：MiMo Code 到底加了什么？这些加的东西值不值得一个独立项目的存在？ 从 OpenCode 到 MiMo Code：不是换层皮那么简单 先说上游项目。OpenCode（现在叫 opencode）是一个终端原生的 AI 编程助手，17 万+ Star，TypeScript 写的，支持多 Provider、TUI 界面、LSP、MCP 协议和插件系统。它在 2025 年 4 月创建，到现在已经迭代了一年多，是终端编程 agent 领域里用户量最大的开源项目之一。 MiMo Code 保留了 OpenCode 的所有核心能力——多 Provider 切换、TUI 交互、LSP 集成、MCP 工具协议和插件系统——在此基础上叠加了五个关键模块。从源码结构看，它在 packages/opencode 目录下保留了 OpenCode 的核心代码，同时新增了 packages/app、packages/desktop、packages/enterprise、packages/sdk 等模块，看起来不只是一个 CLI 工具，而是一个完整的平台化产品。 持久化记忆系统 —— 这可能是最有意思的部分。它用 SQLite FTS5（全文搜索）做底层存储，维护一个 MEMORY.md 文件作为跨会话的项目知识库。每次你开新会话，记忆自动注入上下文，agent 不需要重新理解项目结构。 ...

我越来越觉得，很多 AI Agent 的问题不在“模型还不够聪明”，而在我们把它们塞进了一个很别扭的接口里：一条聊天消息进来，一条聊天消息出去，中间所有思考、工具调用、观察结果、用户反馈，都被挤在同一条时间线上。 这件事平时不明显。你让模型改一段代码、总结一篇文章，它慢一点、啰嗦一点，问题不大。但一旦进入真正的 Agent 场景，比如浏览器操作、长时间代码修改、后台任务、多人协作，它就开始露馅：模型正在“思考”时没法同时接收新信息，正在“输出”时没法真正读环境变化，正在等工具结果时也没法继续做别的规划。 说白了就是：我们想要一个能并行工作的智能系统，却还在用单线程聊天窗口来驱动它。 最近 HN 上有一篇论文讨论的正是这个问题：Multi-Stream LLMs: Unblocking Language Models with Parallel Streams of Thoughts, Inputs and Outputs。它的分数不算特别夸张，但我觉得比很多“又一个 Agent 框架”更值得写。因为它不是在 prompt 外面再包一层流程图，而是在问一个更底层的问题：LLM 的交互格式，是否已经成为 Agent 能力的瓶颈？ HN 原帖标题也很直接：Multi-Stream LLMs: new paper on parallelizing/separating prompts, thinking, I/O。这不是一个已经成熟可用的工程框架，更像是一份架构提案。但它戳中了生产级 Agent 的一个痛点。 当前 Agent 最大的隐性假设：所有事情都必须排队 今天大多数 Agent 系统，本质上还是 ChatGPT 时代的消息协议： system message 定规则； user message 给任务； assistant message 生成回答或工具调用； tool message 把结果塞回上下文； assistant 再继续。 OpenAI 的 Agents SDK 已经把 handoff、guardrails、tracing、tool calling 封装得很清楚；Anthropic 的 Computer Use 也让 Claude 可以观察屏幕、点击、输入、等待环境变化；MCP 则通过 Model Context Protocol 把外部工具和数据源标准化成可连接的上下文。 ...

本地 LLM 做 Agent，最容易被低估的不是模型能不能回答问题，而是它能不能稳定地把一串工具调用跑完。 这句话听起来有点扫兴。毕竟现在 7B、8B、14B 模型的 benchmark 分数越来越好，Ollama、llama.cpp、llama-server 也把本地部署门槛降到了很低。我之前写过一篇 本地 LLM 推理工具的取舍，当时重点放在推理后端、模型格式和生态锁定上。但如果你真的想把本地模型接进自动化工作流，另一个问题会更快冒出来：模型单步看起来不错，多步之后为什么还是崩？ HN 上这两天有个项目 Forge 很适合拿来讨论这个问题。它的标题很抓人：“Guardrails take an 8B model from 53% to 99% on agentic tasks”。我对这种数字一向谨慎，因为 agentic task 的定义、评测场景和采样参数都会强烈影响结果。但 Forge 真正值得看的地方，不是“8B 追平 frontier model”这个营销点，而是它把本地 Agent 失败拆成了几个非常工程化的小故障：工具调用解析失败、走错步骤、错误恢复失败、上下文预算失控，以及多个工作流争用同一个 GPU 推理槽。 说白了，它不是在训练一个更聪明的模型，而是在给一个不够稳定的模型加流程控制。 为什么本地 Agent 会在多步任务里快速掉队 很多人第一次做工具调用 Agent，会拿一个天气查询、数据库查询或者代码搜索 demo 开始。模型需要做的事情很简单：读用户问题，选择工具，填参数，拿结果，再回答。单步成功率只要看起来有 90%，体验就会很好。 问题出在复合任务上。 假设一个工作流有 5 步，每一步成功率都是 90%。如果这些步骤必须全部正确，整体成功率不是 90%，而是 0.9 的 5 次方，大约 59%。这还是独立错误的理想情况；真实 Agent 里，前一步的轻微偏差会污染后续上下文，错误会复利。 Forge 作者在 HN 发布帖 里也用了类似的“compounding math”解释：本地模型每一步都不算太差，但连续工具调用会把小错误放大成任务失败。这其实是我最认同它的地方。生产环境的 Agent 可靠性，很多时候不是靠“再换一个大模型”解决，而是靠把可控部分从自然语言里拿出来，交给确定性系统。 这也是为什么我会把 Forge 和之前写过的 Statewright 状态机护栏 放在同一类问题里看。Statewright 更偏“限制 Agent 在什么阶段能做什么”，Forge 更偏“当模型工具调用出错时，如何修、如何重试、如何阻止它跳步骤”。两者的共同点是：它们都不再迷信一个超长 system prompt。 ...

我对“给 Agent 做代码搜索”这类工具一直有点警惕。 原因很简单：很多产品把问题讲成“grep 太笨，向量检索更聪明”，最后落地却变成另一个黑盒。Agent 找不到符号定义时，开发者至少还能看见它 grep 了什么；如果换成一个语义搜索服务，结果看起来更像魔法，但错的时候也更难排查。 所以看到 HN 上的 Semble 时，我第一反应不是“又一个代码 RAG”，而是问一个更工程化的问题：编程 Agent 到底需要什么样的代码搜索？ Semble 的答案挺明确：它不是给人做 IDE 搜索，也不是给企业做大规模代码知识库，而是给 Claude Code、Codex、Cursor、OpenCode 这类编程 Agent 提供一个本地、低延迟、少 token 的代码检索层。HN 原帖标题也很直接：Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep。截至我写这篇时，项目在 GitHub 上已经超过 1000 stars，最近提交也在 2026 年 5 月，至少不是一个空 README 项目。 为什么 grep 对 Agent 不够友好 人用 grep，其实会做很多隐性判断。 你搜 auth，看到 30 个文件，会快速扫目录名、测试文件、legacy 文件，再决定先打开哪个。你会知道 auth_test.py 不是主实现，compat/ 里可能只是兼容层，AuthProvider 的定义比调用点更重要。 Agent 就没这么省。 它通常会先 grep，一个关键词命中几十个文件，然后 read 一堆文件。每多读一个文件，就多消耗上下文窗口、多花钱、多增加模型注意力噪声。更麻烦的是，Agent 经常会被“看起来相关”的调用代码带偏，最后改了外围逻辑，真正的核心函数反而没碰。 ...

如果你用过 Claude Code、Codex CLI 或 Cursor 这类编程 Agent，大概率见过一种很烦人的失败模式：它明明已经读完文件，却又回头读一遍；明明应该先写测试，却开始大面积重构；明明只是修一个 20 行 bug，却顺手动了 6 个模块。最后 token 花了，diff 也出来了，但你不敢合并。 我越来越觉得，这不是“模型不够聪明”一个问题。 更准确地说，是我们把 Agent 放进了一个没有交通规则的城市：Read、Grep、Edit、Bash、Web、MCP 工具全都摊在它面前，然后指望一段系统提示词告诉它“请谨慎驾驶”。提示词当然有用，但它不是刹车，也不是红绿灯。 这也是 Statewright 最近在 HN 上引起我注意的原因。它的口号很硬：Agents are suggestions, states are laws. 用人话翻译：不要只靠模型“自觉”，把工作流拆成确定状态，在每个状态里只开放它该用的工具。 状态机不是新概念，但放在 Agent 上刚好戳中痛点 Statewright 做的事情并不神秘。它让你定义一个工作流，例如 planning → implementing → testing → completed。在 planning 状态里，Agent 只能读文件、搜索代码；进入 implementing 以后才允许 Edit/Write；到 testing 状态，Bash 可以用，但只能跑 pytest、cargo test、npm test 这类白名单命令。 项目 README 里的示例很直观：planning 只给 Read/Grep/Glob，implementing 允许 Read/Edit/Write 且限制 max_edit_lines、max_files_per_state，testing 才给 Bash，并且通过 guard 判断测试是否通过。官方的 workflow schema 也把这些字段明确写成结构化配置，而不是自然语言建议。 ...

如果你正在做 AI Agent，有一个问题很容易被忽略：Agent 到底需不需要一个很大的模型来“选择工具”？ 我以前默认答案是“需要”。毕竟工具调用看起来像推理：用户说“明天早上 8 点提醒我带伞”，模型要理解意图、找到日历或提醒工具、抽取时间、地点和参数，最后输出一段合法 JSON。让 7B、14B 甚至更大的模型来做，似乎很自然。 但这两天 HN 上的 Needle 把这个直觉反过来了。Cactus 团队开源了一个只有 26M 参数的 function calling 模型，README 里说它是把 Gemini 3.1 的工具调用能力蒸馏到一个 “Simple Attention Network” 上，目标是跑在手机、手表、眼镜这类消费设备上。项目目前 MIT 开源，代码在 cactus-compute/needle，权重放在 Hugging Face。 26M 是什么概念？比很多 embedding 模型还小，比常见的 0.5B/1.5B 小模型又小一个数量级。它不打算写诗、聊天、做数学题，只做一件事：给定用户 query 和工具 schema，吐出应该调用的工具及参数。 坦白说，我觉得这个方向比“又一个端侧聊天机器人”更值得写。因为生产里的 Agent 系统，最先遇到瓶颈的往往不是“模型不够聪明”，而是“每一步都太贵、太慢、太不稳定”。 把工具调用从“推理”降级成“路由” Needle 的核心判断很激进：单轮工具调用本质上不是开放式推理，而是 retrieval-and-assembly。 用人话说，就是三步：先从工具列表里匹配哪个工具最像用户意图；再从用户句子里抽参数；最后按 schema 拼成 JSON。这个过程当然需要语言理解，但它未必需要一个装满世界知识的大模型。工具说明和参数 schema 已经作为输入给了模型，事实知识在上下文里，不必塞进 FFN 权重里。 这也是它的架构为什么反常。Needle 的 Simple Attention Networks 文档 里明确写到：实验发现，如果任务依赖外部结构化知识，Transformer 里的 MLP/FFN 可以被完全拿掉，模型主要靠 attention 和 gating 工作。Needle 的结构是 12 层 encoder 加 8 层 decoder，隐藏维度 512，8 个 attention head，BPE 词表 8192；README 还强调 “no MLPs anywhere”。 ...

如果你已经习惯让 Claude Code 或 Codex 写业务代码，那么下一个很自然的问题是：能不能让同一个 Agent 顺手把产品原型、落地页、PPT、甚至一段演示视频也做出来？ 我以前对这类“AI 做设计”的项目比较警惕。原因很简单：很多工具只是把 prompt 包了一层漂亮 UI，最后产物看起来像模板站，改两轮就塌。但最近 Hacker News 上的 Open Design 让我多看了几眼。它不是另一个单点生成器，而是把 Claude Code、Codex、Cursor Agent、Gemini CLI、Qwen、Copilot CLI 等命令行编码 Agent 当成“设计引擎”，再叠一层本地优先的技能、设计系统、沙盒预览和导出链路。项目 README 直接把自己定位成 Claude Design 的开源替代。 这句话听起来很大，但工程上真正有意思的不是“替代 Claude Design”，而是它暴露了一个更具体的搜索问题：设计工作流到底应该由专门的设计模型驱动，还是由已经会读文件、改代码、跑命令的 Coding Agent 驱动？ 我的判断是：Open Design 不一定会马上成为生产级设计平台，但它代表了一条很值得关注的路线——把设计从“生成一张图”拉回到“生成一个可运行、可审查、可导出的工程项目”。 它不是文生图工具，而是把设计任务工程化 Open Design 的 README 里有几个关键词很关键：local-first、BYOK、agent CLI auto-detect、Skills、Design Systems、sandboxed preview、HTML/PDF/PPTX/MP4 export。翻成人话就是：它不试图自己训练一个万能设计模型，而是把你机器上已有的 Agent CLI 调起来，让 Agent 在一个受控项目里生成和修改设计资产。 这和很多 AI 设计产品的差别很大。后者通常是“输入一句话，得到一个不可解释的视觉结果”；Open Design 更像是“给 Agent 一个设计系统、任务说明和预览环境，让它持续修改文件，直到产物可运行”。 说白了，它把设计任务变成了一种软件工程任务。 这件事的价值在于可迭代性。一个登录页、一份销售 deck、一个移动端交互原型，本质上不只是图片，而是一组结构、样式、文案、资源和导出规则。Coding Agent 已经擅长处理这些东西：读项目、改组件、运行构建、根据错误日志修复。Open Design 做的是把这些能力迁移到设计场景。 这里我会联想到之前写过的 Claude Code Routines：真正稳定的 Agent 工作流，很少靠一次神奇 prompt，而是靠可复用步骤、上下文约束和反馈循环。Open Design 的 Skills 和 Design Systems，本质上也是在给 Agent 建立可复用的“套路”。 ...

你有没有这种感觉：每天早上醒来，前一天学的东西大部分都忘了？ LLM 就是这样工作的。 每个对话 session，模型都是从零开始。它不记得你是谁，不记得你上次做了什么决定，更不记得那个方案三个月前就试过并且失败了。你花 20 分钟解释背景，下一个 session 又得重来一遍。 这不是 AI 的 bug——这是架构限制。大多数 Agent 的"记忆"，就是把整段对话历史塞进 prompt，靠上下文窗口撑着。贵、慢，而且换一个新 session 照样失忆。 Stash 想要解决这个问题。它的 slogan 很直接：Your AI has amnesia. We fixed it. 这个项目是做什么的 Stash 是一个开源的持久化记忆层，专门给 AI Agent 用。它不是一个聊天机器人，而是一个基础设施——在 Agent 和外部世界之间加了一层认知处理管道。 核心思路：Episodes become facts. Facts become patterns. Patterns become wisdom. AI 的每一次对话、每一个决定、每一次成功和失败，都被记录下来，经过一个 8 阶段的管道，转化成结构化的知识。事实与事实之间建立关联，关联形成模式，模式沉淀为真正的理解。 原始对话 ↓ Episode 记录（原始事件） ↓ Fact 提取（去掉了时间戳和情绪的事实） ↓ Relationship 建立（事实之间的连接） ↓ Pattern 检测（反复出现的模式） ↓ Goal Tracking（目标状态） ↓ Failure Pattern（失败教训） ↓ Hypothesis & Confidence（假设与置信度衰减） ↓ Wisdom（长期知识） 这个管道是增量的——每次运行只处理新数据，不会重复劳动。 ...

如果你在生产环境跑过 AI Agent，大概率遇到过一个头疼的问题：Agent 怎么安全地访问那些需要 API Key 的服务？ 传统方案很简单：把密钥配置在环境变量里，Agent 启动时读取。但这套逻辑是给"确定性程序"设计的——程序行为可预测，不会被外部指令诱导去做你没想过的事。 AI Agent 不一样。它们是非确定性的，能被 prompt injection 诱导，能被恶意网页操纵，能在 RAG 流程里接收有害指令。密钥一旦进了 Agent 的上下文，就等于随时可能被抽走。 这是一个真实存在的威胁，不是理论推演。Infisical 最近的博客详细描述了攻击路径：攻击者通过文档注入、恶意网页或工具调用让 Agent “主动"把环境里的密钥发到攻击者控制的端点。哪怕你上了多层 guardrails，也没有办法保证 Agent 绝对不泄露。 传统解法为什么不够用 业界的应对思路大概分三类： ① 短命凭证（Short-lived Tokens） OAuth2 的 access/refresh token 模式，API 返回临时凭证，过期自动失效。配合自动化密钥轮换，攻击者拿到的那串字符很快变成废纸。 听起来合理，但本质上只是降低窗口期，没有解决根本问题——凭证依然会泄露，攻击者只要在失效前用完就赚了。 ② 防火墙和网络隔离 只允许 Agent 访问特定 IP 段，不允许出站直连。攻击者通过 Agent 发起请求，同样会经过那些被允许的端点，该泄露还是泄露。 ③ 自行实现凭证代理 Anthropic 的 Managed Agents 架构、Vercel 的 credential brokering、Cloudflare 的 outbound workers，都走了同一条路：Agent 的请求经过一个代理层，由代理负责在请求发出前把凭证注入，Agent 自己从不直接接触密钥。 这条路是对的，但每家公司都得自己造轮子。 Agent Vault 的思路 Infisical 新开源的 Agent Vault 把这条路做成了通用产品。它的核心设计原则只有一条：Agent 永远拿不到金库里的密钥，只能通过代理间接使用。 ...

你选了一个Kimi K2的第三方API提供商，省了30%的成本。结果线上agent跑着跑着开始乱调用工具——你以为模型有问题，实际是API供应商的工程实现挖的坑。 这不是段子，是真实发生的。MoonshotAI最近开源的 K2 Vendor Verifier（551 Stars）干了一件事：他们对市面上的Kimi K2第三方API做了套标准化精度测试，结果发现同样一个模型，经不同厂商分发后，toolcall精度可以从100%掉到76%。 背景：K2的核心能力就是toolcall Kimi K2是MoonshotAI发布的专注于Agent场景的LLM。什么叫"专注Agent"？说白了就是它的核心能力不是聊天，而是toolcall——让模型学会调用外部工具完成复杂任务。 这类能力对精确度要求极高。一次toolcall失败，可能导致整个agentic loop崩溃： 工具ID格式错误 → 解析异常 JSON Schema不匹配 → 调用参数丢失 触发时机错误 → 该调工具时模型"停了" 所以K2的toolcall精度不是"体验问题"，是"能不能用"的问题。 测试方法：和官方API同题作答 K2VV的测试思路很直接：用同一套4000条测试请求，分别走官方MoonshotAI API和各第三方厂商API，对比toolcall结果。 核心指标就两个： ① tool_call_f1（触发精度） 模型该不该调用工具、该调用哪个工具。用F1分数衡量，和官方API对比。 ② schema_accuracy（Schema符合度） 模型决定调用工具了，但它生成的JSON参数对不对。用通过schema验证的比例衡量。 结果？差异触目惊心。 数据说话：同卷不同分 K2-thinking版本（temperature=1.0，max_tokens=64000）的成绩单： 厂商 schema_accuracy MoonshotAI（官方） 100% Fireworks 100% InfiniAI 99.89% SiliconFlow 98.96% GMICloud 95.95% vLLM（自托管） 87.22% DeepInfra 86.91% GoogleVertex 85.76% Together 84.63% vLLM自托管版本，schema精度只有87%——意味着每100次toolcall，13次生成的参数过不了schema校验。这在生产环境里是什么概念？你的agent每天跑1000次toolcall，有130次会在运行时崩溃。 K2-0905-preview版本（temperature=0.6）的数据更明显： 厂商 schema_accuracy MoonshotAI（官方） 100% SGLang（自托管） 73.13% vLLM（自托管） 76.00% Volc 72.86% SGLang和vLLM这两个最流行的开源推理框架，精度都没过80%。 根因分析：三个工程坑 K2VV的维护者直接点名了三个最常见的问题： ...