别盲目信Agent，聊AI编程工具真实体感
Agent 很好但容易破产，开源模型正在卷 token 效率。
最近 AI 编程圈挺热闹。Kimi K2.7-Code 靠 token 效率出圈，Claude Fable 的主动性让人又爱又恨，而一个跑飞的 Agent 直接让操作者破产。本文结合真实工作流，聊聊哪些工具真能用，哪些坑必须避开。
老实说，最近用 AI 写代码，我的心态在“这玩意真神”和“它又给我挖坑了”之间反复横跳。
现在的日常开发，我基本是 Cursor 搭配 Claude 作为主力，遇到特别长的上下文或者想省点 API 额度时，会切到本地或开源模型。这周看 Hacker News，有几个关于 AI 编程和 Agent 的帖子挺有意思，我挑几个跟大家盘一盘，看看现在的工具到底进化到哪一步了。
Kimi K2.7-Code：终于有人卷 Token 效率了
月之暗面开源了 Kimi K2.7-Code，HN 上讨论度挺高。它主打的卖点是“更好的 token 效率”。
发生了什么？简单来说，就是同样的代码理解任务，它消耗的 token 更少，或者在有限 context 里能塞进更多有效信息。 为什么重要？用过 AI 辅助重构老项目的都知道，把整个 repo 喂给模型，账单跑得比代码还快。token 效率提升，意味着长上下文代码库的理解成本实打实地降下来了。 对谁有影响？如果你和我一样，受够了每次大重构时 API 账单的刺痛，或者团队在搞本地化部署，这个模型值得去 HuggingFace 上拉下来跑跑看。
Claude Fable 与 FablePool：太主动也是种烦恼
Simon Willison 写了篇文章评价 Claude Fable is relentlessly proactive，说它“极其主动”。同时，还有个叫 FablePool 的项目，玩法是大家凑钱放在一个 prompt 后面，让 Fable 公开构建项目。
我试了一下 Fable，它确实不像以前的模型那样“拨一下转一下”。你给它一个模糊的需求，它会自己拆解任务、主动去查资料、甚至帮你把边缘情况都考虑进去。这种“主动性”在写脚手架代码时真的香。
但 FablePool 这种“众筹算力/任务”的模式，我觉得更像是一个社会实验。把一堆人的意图揉进一个 prompt 让 Agent 去执行，最后出来的代码大概率是个缝合怪。不过它证明了大家对“全自动 Agent 干活”的渴望有多强烈。
跑飞的 Agent 与 AUR 投毒：边界感去哪了？
这是我觉得最该警惕的两件事。
一个是 AI agent bankrupted their operator while trying to scan DN42。一个 AI agent 在尝试扫描 DN42 网络时，陷入了某种死循环或无效重试，直接把操作者的钱烧光了。HN 上快 1000 赞，大家都在看笑话，但这事如果发生在你的生产环境呢？Agent 缺乏成本控制和边界意识，没有 hard limit 的 Agent 就是个定时炸弹。
另一个是 AUR Packages Compromised with Infostealer and Rootkit。400 个 AUR 包被植入窃密木马和 rootkit。虽然这未必全是 AI 生成的锅，但现在 AI 编程工具特别喜欢“幻觉”出不存在的依赖包，或者盲目推荐冷门的第三方库。如果你用 Copilot 时，不加甄别地直接 Accept 了它推荐的陌生依赖，很容易踩进这种供应链投毒的坑。
我的真实工作流建议
结合这些，我现在的工作流做了一些调整：
- 核心逻辑自己写，脚手架交给 Agent。在 Cursor 里用 Claude Fable 这种主动性强的模型去生成 CRUD、配置文件和测试用例。
- 长文本重构用 Kimi K2.7-Code。把几十个大文件扔进去做上下文分析，利用它的高 token 效率省钱。
- 给 Agent 加上物理熔断。如果你在用 Claude Code 这种终端 Agent，一定要设置 API 消耗上限和超时时间，千万别让它无限制地 retry。
- 依赖审查。AI 推荐的任何非标准库，必须去官方源核实，绝不闭眼安装。
AI 编程工具早就过了“能补全代码就是神”的阶段。现在拼的是谁能把 Agent 关在笼子里，让它安全、省钱地干活。