Kimi 把 Harness 做成了云服务，但有三样东西它给不了

11 月 5 日，月之暗面发布 Kimi Hosted Agents，把支撑 Agent 运行的那层 Harness，做成了云服务。

配套的东西挺实在：140 多个 Skills、30 多个插件、独立沙箱、网络权限控制、会话可中止并可导出审计，还有推理前的拦截钩子 —— 按企业规则，在模型推理之前把敏感数据挡住。首批给了 8 个金融 Agent 模板。

这条消息在朋友圈刷了一轮。多数解读停在「企业不用自己搭框架了」。

我的看法要冷一点。

省下的是搭建成本，省不下的是你对自家业务的理解。

01 先说它真解决了什么：轮子终于不用人人再造一遍

过去两年，每一家做 Agent 落地的团队，都在重复造同一套东西。

重试机制、结果校验、工具编排、权限控制、审计留痕。这五样东西，任何一样做不好，Agent 就上不了生产；但任何一样做好，都不产生一分钱业务价值。

这就是它尴尬的地方：它是必需品，却不是竞争力。

一个团队花三个月搭出来的运行时，和另一个团队花三个月搭出来的，能力上不会有本质差别。这三个月不产生差异化，只产生 "终于可以开始了"。

现在有人把它做成了水电。对小团队来说，这是实打实的利好：

原本要三个月的活，现在可以一周起步。原本要招一个专职做运行时的人，现在可以把这个人放到业务侧。原本因为 "基础设施太重" 而搁置的场景，现在值得拿出来试一试。

基础设施的民主化，历来是这样发生的：它不创造新的可能性，它把原来的门槛拆掉。

门槛拆掉之后，跑起来的人会变多。但跑起来，不等于跑对。

02 但最值钱的三样东西，云服务给不了

这是我想说的核心。

Harness 里最值钱的三样东西，厂商做不进标准件里：你的口径、你的规则边界、你踩过的坑。

第一样，你的口径。

同一个 "销售额"，销售算签单、财务算回款、运营算 GMV。这不是数据问题，是组织问题。厂商不知道你们公司最后以谁为准，也不知道这个口径在三年前改过一次、为什么改。

它可以给你一个配置项，让你填口径；但它不知道该怎么填。而这个 "怎么填"，恰恰是让模型答对问题的前提。

第二样，你的规则边界。

什么样的操作需要谁批、哪些数据对一个角色可见、哪些例外历史上被允许过、哪条红线一次都不能碰。

这些规则，一部分写在制度里，一部分散在会议纪要里，还有一部分只在几个老员工脑子里。厂商能给你权限引擎，给不了你规则本身。

第三样，你踩过的坑。

那次因为混用口径被财务打回来、那次因为读了一张废弃表给出错误结论、那次因为自动执行了一个本该审批的动作。这些坑，是你们公司独有的历史。

它们没法被通用化，只能被本地化。而它们恰恰是让 Agent 从 "能用" 到 "可信" 的关键材料。

所以那个说法要小心：厂商给你的是骨架，血肉得自己长。

「接入即落地」是最危险的六个字。骨架能让你跑起来，但跑对方向靠的是本体 —— 你对自家数据关系、业务规则、历史现实的理解。

一个没有本体的 Agent，接入云服务之后，只是变成了一个跑得更快的、不懂你公司的 Agent。

03 这次更新里，最该被注意的其实是两个能力

和企业选型直接相关的，我认为是两件事：审计可导出、推理前可拦截。

很多人会盯着 140 个 Skills 和 8 个金融模板，那是 "能做什么"。但真正决定项目生死的，往往不是 "能做什么"，是 "能不能通过评审"。

我见过太多 Agent 项目死在安全评审会上。不是能力不够，是说不清三件事:

它拿了什么数据？ 它做了什么？ 出了事能不能追？

前两个问题，过去两年靠 "我们写了日志" 来回答，但日志在自己系统里、格式自定义、随时可改，评审方不认。现在审计可以导出，等于把 "可追溯" 做成了标准件。

第三个问题更微妙。"能不能追" 不只是有没有记录，而是记录能不能被第三方独立核查。可导出这件事的意义，不在于方便，在于它让日志具备了证据属性。

推理前拦截也一样。这个能力的价值不在 "能拦", 而在 "拦得早"。等模型推理完了再过滤输出，敏感数据已经在上下文里过了一遍；在推理之前就挡住，数据根本没进模型。这在金融、医疗这类场景里，是完全不同级别的合规姿态。

厂商把这两个能力做成标准件，等于替你回答了一半评审问题。

另一半还是你的:

数据分级做了没？谁能批？出了事谁签字？

这才是真正的分水岭。同样一套云服务，有的公司能通过评审，有的公司通不过，差别不在技术，在这三个问题的答案有没有落成制度。

04 一个可操作的建议：别拿生产数据试水

道理讲完，给一条明天就能做的。

找一个内部场景，先跑两周。

不要挑最性感的场景，挑那种既真实、又低风险的活。报销政策问答、合同条款比对、内部制度查询 —— 这类场景有三个好处：有真实问题、有标准答案、错了代价可控。

然后把权限收到最紧:只读。

不给写，不给发，不给调外部接口，就让它查、让它答、让它引用来源。

两周之后，做一件比看报告更重要的事:把审计日志拉出来，从头到尾看一遍。

看什么？看它查了哪些你没想到它会查的数据，看它在哪些问题上绕了远路，看它引用了几次过期文档，看它在哪里 confidently 地答错。

看完那份日志，你会比读十篇解读更清楚这套东西适不适合你。

因为那份日志不会说谎。它记录的不是产品能力，是你的业务现实被一个外部系统理解到了什么程度。

我甚至认为，这两周的产出不是 "一个能用的 Agent", 而是一份关于你公司本体缺失点的清单。哪个口径没定、哪张表没人维护、哪条规则只存在于口头 —— 日志会一个个指给你看。

这份清单的价值，比 Agent 本身大得多。

05 再往深一层：Harness 商品化之后，竞争点在哪

如果 Harness 真的变成了云上的水电 (而且大概率会，不止一家在做), 那么企业之间的差距会怎么变？

我的判断是:差距会从 "有没有框架", 迅速迁移到 "本体有多厚"。

这个迁移已经在发生。

过去，能不能做出 Agent, 取决于工程能力：会不会编排、会不会做权限、会不会做审计。这是一道技术门槛，能跨过去的人不多，所以跨过去本身就是优势。

现在这道门槛在被铲平。铲平之后，所有人都能跑起来，那么跑得快不快、跑得对不对，就取决于另一件事:谁更懂自己的公司。

而 "懂自己" 这件事，没有规模效应，也没有外包可能。

它需要有人一条条理口径，一次次对齐权限，一份份喂历史决策，一轮轮纠偏。它是慢的、脏的、不性感的。它不会出现在发布会的 PPT 上，但它决定了发布会的成果能不能活过三个月。

所以这一轮之后，我建议企业重新排一下自己的投入结构:

花在选型上的时间，应该往下调。 花在建本体上的时间，应该往上调。

模型每半年换一代，今天的惊艳明年就是标配；而本体是会增值的资产，模型越强，它释放的价值越大。同样一份高质量的本体，喂给今年的模型是七十分，喂给明年的模型可能是九十分 —— 因为限制它的从来不是模型智力，而是它对你公司的理解程度。

结语：脚手架不稀缺了，稀缺的是你有多懂自己

回到那条消息。

Kimi 这次的发布，是一次很实在的基础设施供给。它把一个原本人人都要重复造的轮子，变成了可以按需取用的服务。这件事值得肯定，也确实会改变很多团队的节奏。

但它改变的是起点, 不是终点。

起点变低了，所有人都能更快出发。终点在哪，还是取决于你对自己的业务了解到什么程度。

脚手架越来越不稀缺了。稀缺的，是你对自己公司有多了解。

三个可以带走的判断:

01 基础设施商品化，不会消灭竞争，只会把竞争推到更靠内的地方。 从 "会不会搭" 推到 "懂不懂业务", 这不是变简单了，是变难了 —— 因为后者没法采购。

02 云服务能替你回答评审问题的一半，另一半必须自己写。 数据分级、审批权限、责任签字，这三件事没有标准件。

03 拿两周做一次低成本试水，产出物是缺失清单，不是 Agent。 那份清单，才是你后续所有投入的真实地图。

延伸思考，留给正在选型的人:

如果现在给你一套开箱即用的 Agent 云服务，你能立刻说出你们公司的 "销售额" 最终以谁的口径为准吗？

你们的安全评审，能接受 "审计日志可以导出" 作为证据，还是必须看到数据分级和责任人名单？

过去两年，你们的投入是在买模型，还是在养本体？