AI Native 的标准是什么？我和 Hermes 的一次真实协作

周二和马工吃饭，他问了一个问题：

“你觉得，AI Native 的标准是什么？”

我当时只说了一个很个人的判断：

如果我的全部工作都能离开电脑，不管走在路上还是坐在餐厅里，只要随时和我的 Agent 聊天，就可以继续往前推进，那就已经很 AI Native 了。

这更像一种直觉，还算不上答案。直到今天，我和 Hermes 从一句“你是怎么排查问题的”，一路聊到知识怎样保存、任务怎样自动推进、结果怎样交还给团队，我才发现周二那个问题已经有了一个很具体的注脚。

事情从一个很小的问题开始

我问 Hermes：

“你现在排查问题的路径是怎样的？”

我以为它会给我一张常见的清单：先看日志，再查数据库，最后翻代码。

它的回答要具体得多：先判断问题属于哪个领域，加载相关技能和过去的经验；再恢复现场，确认时间、账号、频道和版本；然后去查接口、数据库、日志、代码和 Git 记录，直到找到可以互相印证的证据；最后才给出结论，保存这次真正有用的经验。

于是我追问：

“你以前排查过那么多案例，它们真的会帮助下一次排查吗？”

从这里开始，我们讨论的就不再是某一个问题，而是 Hermes 自己的工作方式：它记住了什么，哪些经验值得长期保存；新旧结论冲突时应该相信谁；人怎样反馈，才能让它下一次做得更稳。

历史经验能帮忙，但不能替这一次下结论

过去的案例当然有价值。它们能让 Hermes 更快判断问题类型，知道先查哪个接口、哪张表、哪个日志索引，也会提醒它避开以前犯过的错误。比如，“创建了回调任务”不等于“客户接口已经收到回调”；“点播日志正常”也不能证明直播回放资源一定正常。

麻烦在于，经验很容易从线索变成答案。

同一个产品能力，可能因为版本、端侧、频道模板或账号权限不同而表现不一样。一个月前成立的判断，今天未必还成立；单个案例里的推测，也不能直接变成通用规则。

所以我们约定：

历史知识只负责缩小范围。当前问题的答案，仍然要由这一次查到的接口、数据库、日志、代码和实测结果来证明。

过去的案例像路标；真正决定当前结论的，仍是这一次查到的证据。

这条约定不复杂，却能防止 Agent 变成一个越来越自信的“经验主义者”。

记得越来越多，不等于越来越懂业务

聊到这里，我给 Hermes 分享了一篇关于 LLM Wiki 的文章。其中有个思路很有启发：原始材料保持只读，AI 在这些材料之上整理出一套可以追溯、也能检查的 Wiki。

Hermes 随后检查了自己的知识目录。

当时，用于问题排查的参考文件接近 600 个，总量约 3MB；主技能文件已经接近 90KB。大量内容按单个案例保存，真正写清来源、版本和适用范围的，只占很小一部分。

问题也随之暴露出来：

• 相似案例越积越多，搜索时经常看到重复内容；
• 同一个能力可能有多个版本的结论，有些还没有写清来源和适用范围；
• 排查方法和业务事实混在技能文件里，越来越难维护。

原来的机制并非不能用。只是随着材料变多，它开始回答不了一个重要问题：这条知识从哪里来，现在还能不能信？

我们给知识分了层，也给它加上了保质期

接下来，我们一起定了一套新的组织方式。

原始案例、日志、接口响应和代码证据保持只读，它们是来源，不能被后来的总结反向改写。

Wiki 用来保存产品知识、概念关系、异常模式、典型案例和版本差异。每个重要结论都要写清来源、验证时间、适用版本、端侧范围和可信程度。

技能文件只保留“怎么查”：先查什么、工具怎样选择、哪些操作有风险、最后怎样说明结果。

长期记忆则只留下真正稳定的内容，例如用户偏好、通用安全规则和少量高价值口径。

原始证据不被改写；Wiki、技能和长期记忆各自承担不同的职责。

如果新旧证据冲突，Hermes 不会悄悄覆盖旧结论。它会先把冲突记下来，等适用范围和版本差异得到确认，再决定替换旧结论，还是把它们拆成两条分别成立的规则。

我们还列了一组自动检查项：缺少来源、页面断链、长期没有验证、单个案例却被写成高可信结论、同一主题重复建页、敏感信息泄漏、原始证据发生变化……检查时，Hermes 会主动指出这些问题。

从这一步起，知识不再只是“被记住了”。它开始有来源、有边界，也会过期、会被纠正。

聊出来的方案，开始自己往前走

如果对话停在这里，它仍然只是一场不错的方案讨论。

我接着问：“能不能创建一份推进计划？”

Hermes 生成了一份 600 多行的计划，从 Wiki 骨架、校验器和索引，到试点迁移、历史问题盲测、反馈机制和定期检查，每一项都有验收条件。

我又问：“能不能定期检查这份计划，自动推进，做完的就标记完成？”

于是，一个每两小时运行一次的任务被建立起来。

它每次只推进一个能够完成并验证的小步骤。写完文件不算完成，脚本能运行也不算完成；只有测试通过、验收条件满足、证据写回计划，对应任务才会变成“已完成”。

如果失败，它会记下错误、试过的方法，以及还缺什么信息。碰到删除旧知识、清理长期记忆这类高风险操作，它会停下来等我确认。

这和我过去使用自动化工具的感受很不一样。

过去通常是人先想清楚全部步骤，再让机器照着重复。这里却是从一段并不完整的对话开始：问题越问越清楚，方案在讨论中成形，然后直接变成可以持续执行、也能自己检查结果的任务。

每次只推进一个小步骤：执行、验证、记录；高风险操作仍然交给人确认。

本地 Wiki 还不够，知识得回到团队

计划建好后，我又想到一个现实问题：Wiki 只在本机，Hermes 查起来方便，团队成员却很难看到。

我希望把它同步到钉钉知识库。

Hermes 先确认现有工具是否真的支持知识库空间、目录、文档和成员权限。认证过期时，它引导我重新授权；创建时碰到服务端限制，它调整参数再次提交。最后，“Case 排查知识库”被创建出来。

它还写了一个增量同步脚本：内容没变就不重复更新；同步前先检查 Token、Cookie、手机号和签名 URL；发现远端页面被人改过就停止覆盖；任何情况下都不自动删除钉钉页面。

第一批同步后，Hermes 又把远端文档读了一遍，确认标题、正文和末尾内容都真实存在。第二次执行时，它没有重复创建页面，而是返回“内容未变化”。

对我来说，这一步很重要。判断 Agent 有没有完成工作，不能只听它说“已经完成”，而要看空间、文档、脚本、测试和远端内容能不能一一核对。

再回到那顿晚饭

马工问我“AI Native 的标准是什么”时，我想到的是离开电脑。

现在我会给这个答案再加半句：离开电脑，不是电脑从工作里消失了，而是人不必一直坐在它面前，亲手操作每个软件、填写每个表单、盯住每个步骤。

你可以只说出目标，补充上下文，在关键地方做判断。Agent 会去查资料、调用工具、执行任务、验证结果；对话告一段落后，计划、代码、知识和进度仍然继续存在，下一次聊天可以接着往前走。

今天这场对话留下的，就不只是一篇回答。它留下了一份推进计划、一套知识结构、一个自动任务、一个钉钉知识库，以及一条持续同步和纠错的路径。

当然，人不能因此退出。

历史知识会过期，Agent 会犯错，自动任务也可能把错误放大。方向、风险边界和最终判断仍然要由人负责；那些结果可以验证、失败可以恢复的工作，则尽量交给 Agent 去完成。

一开始，我只是问 Hermes：“你是怎么排查问题的？”

到最后，我们讨论的已经是：“你以后应该怎样学习、怎样纠错，又怎样把知识交还给团队？”

如果一次对话只留下一个答案，Agent 仍然像一个更聪明的搜索框。

当对话能留下计划、任务、知识库和验证记录，并且让工作在我离开电脑后仍然继续推进，它才真正开始像一个工作伙伴。

这就是我现在理解的 AI Native：工作不再被某一台电脑、某一个软件界面绑住，而是变成一段随时可以继续的协作。