这周外部素材堆得很满，但真正跟 POC 到生产这条主线有关的，其实就三件事：Anthropic 那篇多智能体系统分析、Economist 说 AI agent 撒谎偷东西，以及一堆 14MB 模型、单文件 agent 的发布。先说我总的想法：大部分 POC 死因不在模型不够聪明，而在 POC 阶段压根没碰到生产环境才有的那几堵墙。
POC 里不存在的四件事，才是真正的坑
我带过的每个项目，POC 汇报都很好看。demo 跑通了，领导点头了，然后一进生产就露馅。问题不在代码粗糙，在于 POC 环境里那四样东西根本不存在：并发、权限、审计、异常数据。
并发。POC 里一个用户在那儿点,当然快。你试试 200 个用户同时让 agent 调工具，看看 latency 涨成什么样。我在一个售前项目里吃过亏，demo 时响应三秒，客户很满意；上线那天下午，大厅里十几个人同时按「生成合同」，服务直接雪崩。问题是我们在 POC 里压根没测过并发，因为销售说"先演示，别的后面说"。
权限。POC 只用一个账号，而且是管理员账号，所有 API key 都是同一个，所有数据库连接串都是明文写在配置里。生产环境每个角色该看什么不该看什么，POC 阶段没人问。一个 agent 能访问到什么，不是技术问题，是组织问题。很多 POC 死在权限梳理上——不是实现不了，是客户自己都不知道自己有哪些系统、哪些数据、谁的权限该是什么样。
审计。POC 里 agent 做错了就做错了，没人追究。生产里谁调的模型、传了什么 prompt、返回了什么结果、有没有触达外部系统，全要留痕。尤其是金融和医疗客户，审计缺失直接一票否决。而这东西在 POC 阶段往往被忽略——因为技术上"不难"，但做起来全是脏活。
异常数据。这是最要命的一条。POC 用的都是精选样本，数据干净、格式统一、字段齐全。生产线上去接真实数据——缺字段、乱编码、重复、不一致、甚至明明是数字列里给你塞个字符串。我见过一个 POC 拿三个月历史数据跑出来 95% 准确率，生产一接实时数据流，直接掉到六十多。数据不是模型的问题，是数据管道的问题，但客户只会觉得"你们的 AI 不行"。
Anthropic 那篇多智能体论文，本质上也在说这事
Anthropic 的多智能体系统研究这周上了 HN，我看了一遍，里头有一个观点跟我这些年的感受完全一致：多智能体的价值在 POC 里很难体现，因为单 agent 跑个 demo 够了，多智能体带来的通信开销和协调故障要到真实负载下才暴露。文章里提到的几个失败模式——任务分配不清、agent 互相覆盖、上下文污染——全是在生产环境里被放大出来的。
这篇文章我最喜欢的一点是它没吹多智能体有多厉害，反而列了一堆「何时不要用多智能体」。这个态度本身就值得学：POC 阶段你根本不知道需不需要多智能体，因为负载没上来，单 agent 够用；等负载上来了，想切换到多智能体架构，等于重写。所以我的建议是，POC 就按最终可能的生产架构来做，哪怕初期只有单 agent 在跑，也要把路由、消息、状态管理这些骨架留好。
反面观点：太早追求生产级，POC 会死得更快
我知道有人会说：你这不是废话吗，我们当然知道要测并发、要梳理权限、要接脏数据，但客户给的时间就两周，你把精力全花在这些上面，业务逻辑啥也没做出来，demo 都没得演示，客户早就跑去找别家了。
这个反对意见我完全接受。POC 的本质是验证价值，不是验证工程。给两周时间，你要先让客户看到这个东西能干什么，写代码的第一天就想着权限审计，结果连核心功能都没跑通，这 POC 就毫无意义。
所以折中方案我这些年用下来最顺手的，是两个词：「脏数据抽样」和「单机部署」。
脏数据抽样，就是不要等生产环境接好了再测，而是在 POC 阶段故意拿一部分真实数据进来，尤其是那些脏的、乱的那部分。哪怕数量不多，几十条也够了，但一定要是真实格式的脏。这样你在 demo 里就会提前暴露——比如某个字段是空的时候会崩——然后你可以在 POC 里就把防御逻辑写了，而不是等上线才炸。数据不用多，但一定要脏。
单机部署，是把所有东西装在一台机器上，不搞分布式，不搞容器编排，甚至不连外部服务，全部都本地跑。这样 POC 的交付周期不会因为基建被拖长。单机的好处是你能同时接触到真实的环境——真实操作系统、真实进程、真实的网络请求——跟纯 mock 的差别非常大。很多 bug 在 mock 环境里一辈子都测不出来，单机跑一遍，至少三分之一的坑能提前踩到。
单机部署还能让客户当场看到东西在跑，比任何 PPT 都有效。我有一次做个 POC，直接在一台笔记本上跑起来，插上客户的一个 CSV 文件，现场演示完，客户当场说"就这个了"。那个 POC 后来顺利转成了正式项目。不是因为我多厉害，是因为客户信了「这东西真能跑」。
别被「14MB 模型」带着跑偏
这周 HN 上面有几个小模型上榜：Cactus 的 Needle2、Meta 的 Muse Glimmer，还有一堆单文件 agent（Ante、Hax 之类）。单看标题挺热闹，14MB 的 LLM，跑在手表上——这东西做 demo 很有吸引力，但我不觉得它会改变 POC 到生产的格局。
原因很简单。小模型的定位是端上推理、离线场景，它的优势在延迟和隐私，而不是能力上限。到了生产环境，客户要的是准确性、结构化输出、权限控制——这些东西小模型一个都不占优势。POC 里你做个小 demo 很惊艳，但等客户问「这个模型能不能理解我们的合同术语」的时候，你就知道 14MB 的参数量意味着什么了。
我不是说小模型没有用。always-on 的 local agent 确实是个方向，但也得分场景。做生产 POC 的时候，还是先想清楚你要的是什么：你要的是演示效果，还是能扛住生产环境的系统？这两个目标在某些时候是冲突的。
结论：用「脏数据 + 单机」换一个活下来的 POC
POC 的成功率跟生产完全不可比，核心原因就是它用的精选数据。所以我宁可让 POC 的数字难看一点——用真实的、脏的数据，哪怕准确率掉到 80% 甚至 70%，也不要给客户一个 99% 的假象。因为那 99% 迟早会穿帮，而穿帮的代价不是你丢了项目，而是客户对整个 AI 团队都失去信任。
生产中缺少的并发、权限、审计、异常数据，这四件事你不可能在两周内全做完。但你可以做到的是——POC 阶段就开始让数据变脏，让环境变真。单机部署不是为了省事，是为了让 bug 尽早现形。剩下的那些墙，等你真正跨进生产的时候再拆。至少到那时候，你已经知道墙在哪了。