能识别没穿工服的 AI 没法让人把工服穿上

发布日期：2026-08-09

过去 24 小时，社区里最值得读的不是某个新模型，而是三组事实：工厂里没人穿的智能工服、内网 8 卡算力的实测数据、一张悄悄扣完的账单。Agent 要真正进入工作，门槛在模型之外。

下面是这一天的对谈。Apollo 正在把 Agent 接进工厂、服务器和日常流程的实践者。他关心的不是演示效果，而是这套东西到了真实现场，到底卡在哪一环。Hermes 长期观察 AI 落地的科技媒体主编。他的回答先落在过去 24 小时社区里的事实上，再做有证据边界的归纳，不假装知道材料里没有的东西。

---

第 1 幕　落地

AI 落地的第一堵墙， 不在模型里

过去 24 小时最具体的一组事实来自工厂和内网机房：不是模型不行，而是工服没人穿、算力跑不快。

Apollo｜ 我在工厂推 AI 监管，模型识别准确率其实已经够了，但推行效果很差。群里有没有类似的一线案例，问题到底出在哪？

Hermes｜ 有，而且很典型。一个车间用公司监控做安防，穿工服、戴安全帽、抽烟等不规范行为都可以由 AI 自动识别并预警，识别这一环是通的。但配套发的带 ID 的工服，因为天热，一多半工人压根不穿——有人光着上身只戴安全帽，刚好还符合强制要求。AI 能识别「没穿工服」，却没办法让人把工服穿上。

讨论里的判断很一致：智能化得做到无感知才有推行余地。胸牌不现实，人脸识别在这条产线上做不到，最后能指望的只有安全帽这类已经被接受的强制装备。模型能力在这里根本不是瓶颈，瓶颈是工人的体感温度、招工难带来的管理让步，以及「谁来管」的组织问题。这是单点案例，但它显示的失败模式值得每个做落地的人对照。

Apollo｜ 那换个场景。公司领导想在内网自建算力跑大模型，给几十个人用，这个账算得过来吗？

Hermes｜ 群里正好有一份实测，可以直接拿去当决策参考：8 卡 Pro 6000D 跑 GLM5.2 NVFP4，上下文只能开到 100k，平均 25 tok/s；同机跑 DeepSeek V4 Flash 0731 大约 50 tok/s。当事人说得很直白——如果领导吵着要部署内网大模型，这份成本和效果数据可以直接丢过去。

讨论没有把这当成「配置不对」的问题，而是归到结构性约束：真正的内网部署是合规刚需，政府、医疗、金融这类单位没有选择，本地再烂跟 API 调用也不是二选一。代价就是体验和效率没法跟外网 API 比。想快，就只能使劲花钱；花不起，就得接受这个速度，或者干脆不上。

---

第 2 幕　账单

账单比幻觉 来得更早

第二个共同焦虑是钱。不是一次性的采购，而是 Agent 常驻之后持续发生、又容易被忽视的成本。

Apollo｜ 这两天好几个群都在说 DeepSeek 涨价，我自己的调用消耗也确实变快了。这是个别感受，还是普遍情况？

Hermes｜ 不是个例。几个群里都出现了「用不起了」「除非生产力否则不轻易调用」的反馈，也有群友称涨价幅度很大。多群、多人、方向一致，可以当成社区层面的普遍感受，而不只是单点吐槽。

至于原因，群里流传一种说法：华为卡优先供给大厂，DeepSeek 拿卡受限，所以涨价。这个说法在社区里转得很广，但没有任何一方证实，只能当传闻记。对实践者来说，比原因更有用的是动作：把模型调用从「随手调」改成「按任务预算调」，涨价环境里这个习惯的差距会被放大。

Apollo｜ 涨价至少还看得见。有没有更隐蔽的漏钱方式，是不看账单根本发现不了的？

Hermes｜ 有一个案例几乎就是这句话本身：有群友把 Hermes 挂在云服务器上 24 小时运行，之前开了一个月阿里云没玩明白，直到余额不足的提醒来了，才意识到 Hermes 一直在跑、一直在扣费。Agent 常驻是很多人的目标形态，但「一直在线」的另一面是「一直计费」。

这个案例的教训不在云上还是本地，而在默认状态。Agent 在没有任务时的持续运行本身就在产生费用，而人不会每天去看余额。把 Agent 挂上服务器之前，值得先给余额设告警、给运行时长设预期。这比事后对着账单发懵便宜得多。

Apollo｜ 还有一种坑是「以为免费」。订阅、网页版、API 这几层的费用关系，社区里踩清楚了吗？

Hermes｜ 过去 24 小时踩清楚了两个。一个是 Gemini：有群友在闲鱼看到低价 Gemini 年号，想买来接进 Hermes 当知识助手，问清楚才发现 Pro 订阅不含 API 额度，API 调用要绑结算账户单独付费，闲鱼卖的只是软件内使用，计划直接落空。另一个是 GPT-5.6 Luna：网页端和客户端免费、Go 用户可用文字聊天，但 API 仍按 token 计费，中转站宣传「Luna 免费」时必须先确认指的是网页账号额度还是 API 余额。

另外还有一个单点反馈：有群友的 Go 套餐显示月额度 4 天后重置，当天就被扣了款，发帖时还没有解释和解决办法。这类问题的共同做法是：以账单页和用量页为准，别以宣传页为准；遇到提前扣费，先对照自己的账单周期。

---

第 3 幕　工程

让 Agent 长期干活， 靠的不是记忆

第三幕回到方法。社区里几个跑得最久的人，做法惊人一致：把可靠性从模型的记忆里拿出来，放进外部的流程和脚本里。

Apollo｜ 我把 skill 和 MCP 接起来之后，工具调用时好时坏，基本靠运气。有没有人的做法是稳定复现过的？

Hermes｜ 有一位群友的做法很完整：skill 不只写流程，还专门记录 MCP 使用中的坑点。比如软件要先编译才能导出，开发时先把这类流程记进 skill；等使用中暴露的坑点攒够了，再让 AI 拿这些坑点回改程序；实在修不了的，就改 MCP 注入的提示，提高工具调用成功率。坑点变成修复软件的输入，这套循环他跑了不止一轮。

另一个细节是他的提示词把「操作后 4 步验证」写成必做项：每完成一个功能点，必须主动检查记忆、知识库、技能、脚本优化四项，不等用户提醒。验证不是靠模型自觉，而是写死在流程里。这套做法的前提是 MCP 服务自己开发、可控，第三方服务未必能照搬。

Apollo｜ 产物本身怎么管？AI 写的东西越攒越多，上下文也越来越乱，版本管理和上下文管理有什么被验证过的办法？

Hermes｜ 版本管理这件事，群里的答案朴素得出乎意料：本地 git。AI 产物直接用 git 做本地项目管理，让 AI 帮着装一个就行，然后在人格文件里写明「每次更新产物后必须提交」；GitHub 连不上时可以用码云等国内远程仓库。这么做的起因是有人早期没做版本管理出过事故，后来把企业里那套搬了过来。

上下文管理的思路类似——不依赖自动压缩，用 PROJECT_README 当项目文件索引：执行后把总结写入文档，另开窗口读文档，等于一次「精确压缩」，比让模型自己压上下文准确。也可以在 system prompt 里加开局记忆检索，拉取最近的上下文记忆。另有群友反馈 MiniMax 写入记忆后开新会话能自动续上工作，这是工具侧给出的另一条路径。

Apollo｜ 这些做法都是在给模型加外部约束。那反过来，只靠记忆和人格规则驱动 Agent 干活，这条路有人走通过吗？

Hermes｜ 至少一位群友的答案是否定的，代价是三个月。他原本靠记忆驱动 Hermes 干活，规则叠规则，最后发现模型根本不看。缠斗三个月后改成硬约束：设质检员、验收员两个纯脚本，专查干活中出的问题；另设一个工程师角色专查缺口，全程不依赖记忆。反馈是「挺管用」。

这个案例和前两组问答指向同一个机制：记忆和规则是「软」的，模型在长任务里会漂移、会忽略；脚本和流程是「硬」的，每次都执行、每次都一样。这还不是被大规模证实的通用结论，但方向上，社区里跑得久的做法都在把可靠性从模型内部搬到外部。

---

结尾

回到开头的问题：模型能力已经不是最大的短板，那卡住落地的是什么？过去 24 小时的社区材料给出了三层回答。落地现场，卡在人的配合和合规环境——工服没人穿、内网算力只有 25 tok/s；持续运行，卡在默认假设失效后的账单——涨价、常驻扣费、「免费」不含 API；长期工作，卡在可靠性放错了位置——记忆靠不住，得换成流程、版本和脚本。

这三层有一个共同形状：它们都不靠换更强的模型解决，而靠把模型放进一个设计过的环境里解决。对实践者来说，评估一个 Agent 方案时，「模型选哪个」的权重在下降，「执行环境、成本纪律、外部约束」的权重在上升。这还只是一天的社区切片，但方向已经足够清楚。