这几天我一直在做一件事：把 Hermes 从一个“能聊天、能调用工具”的 Agent，改造成一个可以长期运行、可以接入企业 IM、可以处理任务、可以被群聊调用的常驻 Agent 节点。
做之前，我以为最难的是模型。
比如用哪个模型做推理，用哪个模型做代码，用哪个模型做长上下文，用哪个模型做便宜的日常问答。
真正做起来以后，我发现模型反而不是第一难点。
真正难的是这些东西：
• Gateway 怎么长期稳定运行；
• 企业微信和飞书的入口怎么隔离；
• 群聊里谁能叫它，叫它能做什么；
• CUA 到底什么时候能用，什么时候绝对不能放开；
• 多 Agent 看起来热闹，实际怎么避免互相污染；
• 出错以后怎么恢复，而不是靠人肉猜日志。
这时候你会意识到一件事：
Hermes 不是一个“更聪明的聊天框”。
一旦它接进企业微信、飞书、群聊和本地工具链，它就已经变成一个服务系统了。
服务系统就不能只按提示词治理。
它要按入口、权限、日志、确认、回滚和恢复来治理。
我现在看 Hermes，不再问“它会不会回答”。
我更关心下面这张表：
这才是常驻 Agent 和聊天机器人的分水岭。
01｜从云端迁到本地后，Agent 就不再是聊天窗口
很多人第一次用 Hermes，会把它当成命令行里的 Agent。
能聊天，能执行命令，能接工具，能写文件，能读上下文。
这个阶段很容易让人产生一种错觉：
只要模型够强，Agent 就能自然变成一个可靠助手。
我的感受正好相反。
当 Hermes 只是你手边的 CLI 工具，它出错的影响半径很小。你看着它，它做错了，你停掉就行。
但当你把它迁到一个本地常驻节点，让它长期在线，再接入企业微信、飞书、群聊、定时任务和本地工具，它的性质就变了。
它不再是一个聊天窗口。
它变成了一个长期在线的入口层。
这时候你要问的问题，不是：
它会不会回答？
而是：
它会不会在错误的人、错误的群、错误的上下文里，执行一个错误的动作？
这两个问题完全不是一个级别。
聊天窗口的问题，通常是回答质量问题。
常驻 Agent 的问题，是系统治理问题。
我现在会先画一张非常粗的架构草图：
这张图看起来很普通，但它能逼你先想清楚一件事：
每条消息到底从哪里来，要进入哪个上下文，最后能不能碰工具。
如果这件事没想清楚，后面模型再强都没用。
02｜Gateway 才是 Hermes 的生产入口
Hermes 里最容易被低估的是 Gateway。
很多人会把 Gateway 理解成“把消息转发给 Agent 的东西”。
这个理解太轻了。
在真实使用里，Gateway 是整个 Agent 服务的入口。
它负责接消息，区分平台，维护会话，处理投递，也可能和定时任务、后台任务、通知链路连在一起。
换句话说：
Gateway 挂了，不是某个机器人暂时不回复。
Gateway 挂了，是整个 Agent 服务入口失效。
更麻烦的是，Gateway 一旦接入多个渠道，问题就会叠起来。
企业微信有企业微信的会话模型。
飞书有飞书的私聊、群聊、@ 机制。
群聊和私聊不是一个风险等级。
单人对话和多人共享上下文，也不是一个风险等级。
你不能只验证“能不能收到消息”和“能不能回复消息”。
真正要验证的是：
• 消息来自哪个渠道；
• 消息来自哪个用户；
• 消息来自私聊还是群聊；
• 当前 session 是否应该复用；
• 当前用户有没有权限触发这个工具；
• 这条消息是否会被错误地投递到另一个上下文。
我会把 Gateway 这层抽象成这样：
这段配置不是让你照抄。
它只是表达一个原则：
Gateway 不能只做接入，它必须和 session、policy、tool、log 绑在一起。
所以我现在看 Hermes Gateway，不再把它当 bot 适配层。
我把它当成 Agent 的 API Gateway。
只不过这个 API 的调用方不是代码，而是人，是群聊，是企业 IM，是定时任务。
03｜企业微信和飞书接入后，问题立刻变成权限系统
接入企业微信和飞书之前，很多问题看起来都很简单。
你发一句话，Agent 回一句话。
但接入企业 IM 之后，问题立刻变成权限系统。
第一层问题是：谁能叫它。
不是所有同事、所有群、所有转发消息，都应该触发 Agent。
第二层问题是：在哪里能叫它。
私聊能做的事，群聊未必能做。
测试群能做的事，正式群未必能做。
第三层问题是：能叫它做什么。
问答、总结、改写、查询状态是一类权限。
读文件、跑命令、调工具、外发消息，是另一类权限。
改配置、提交表单、删除内容、触发审批，又是更高一层权限。
这几个层级不能混在一起。
企业 IM 是权限系统
我踩过的最大坑之一，就是一开始把“能接入”当成“能使用”。
后来我发现，企业 IM 接入的第一原则不是能回复，而是要有边界。
边界至少包括四个东西：
• 用户 allowlist：谁可以触发；
• 群 allowlist：哪些群可以触发；
• 命令 allowlist：哪些动作可以触发；
• 工具 allowlist：哪些工具可以被调用。
如果写成工程化的规则，我会更愿意长这样：
尤其是企业微信这种渠道，一旦你加上群聊能力，就更不能用“默认都可以”的心态。
群聊是公共场。
公共场里的一句话，可能不是命令，可能是讨论，可能是玩笑，也可能是别人转述。
Agent 如果把所有话都当成指令，迟早会出事。
我的结论很简单：
企业 IM 接入不是消息工程，是权限工程。
04｜群聊多 Agent 不该第一天就做成多个机器人
我一开始也很想做那种很酷的效果：
一个群里有多个 Agent。
你 @ 一个，另一个补充，第三个反驳，最后一个总结。
看起来很像一个小型专家委员会。
但真做起来以后，我反而不建议第一阶段就上多个真实机器人。
原因不是做不到，而是不稳。
多个真实 bot 同群协作，会很快遇到几类问题：
• @ 路由是否稳定；
• 谁该回复，谁不该回复；
• 多个 bot 会不会抢答；
• 上下文到底由谁维护；
• A 看到的上下文和 B 看到的上下文是否一致；
• 日志怎么串起来；
• 某个 Agent 失败后，会议怎么继续。
如果这些问题没解决，群里看起来越热闹，系统越不可控。
所以我现在更倾向于一个更稳的做法：
第一阶段，对外只有一个 Bot。
对内做多角色会议协议。
这种方式视觉上没有多个机器人同台那么酷。
但它有几个明显优点：
日志好串。
权限好控。
上下文好管。
出了问题也知道是谁的角色判断出了偏差。
OpenClaw 这类多 Agent 群组方案，我认为很有意思，也值得实验。
但它应该放在第二阶段，作为“群组多 Agent 交互范式”的概念验证，而不是第一阶段就接进正式生产链路。
我的判断是：
多 Agent 真正的难点不是“几个 Agent 能不能说话”。
真正的难点是路由、上下文、权限和恢复。
这些没解决之前，多个 Agent 同群发言只是热闹，不是可靠。
05｜CUA 差点把企业 IM 通道搞乱：它应该是最后手段
这次最让我警惕的是 CUA。
CUA 这类 Computer Use 能力看起来很强。
它能看界面，能点按钮，能操作 App，能在人类界面上补齐 API 做不到的事。
但也正因为它太像人，风险反而更高。
API 调错了，通常还有参数、权限、返回值和错误码。
Shell 跑错了，至少还有命令、退出码和日志。
Playwright 操作网页，至少还有 DOM、选择器和明确动作。
CUA 不一样。
它面对的是视觉界面。
界面可能变。
按钮可能重名。
弹窗可能遮挡。
焦点可能错位。
一个看似小的误点，可能就会变成外发、删除、提交、保存或改配置。
CUA 是最后手段
我这次差点把企业 IM 通道搞乱，就是因为一开始对 CUA 的定位太乐观。
后来我把它降级了。
我的工具优先级现在是：
CUA 不是默认执行层。
CUA 应该只给 Operator 角色。
而且 Operator 在申请 CUA 前，必须说清楚五件事：
这听起来很麻烦。
但只要你把 Agent 接进企业微信、飞书和真实工作流，就必须这么麻烦。
因为这不是模型能力问题。
这是操作风险问题。
06｜常驻 Agent 要按服务治理，不按聊天机器人治理
这次折腾完，我对 Hermes 的看法更明确了。
它很有潜力成为 Personal AI Stack 里的核心层。
但前提是：你不能把它当聊天机器人治理。
你要把它当服务治理。
我现在会把一个常驻 Agent 拆成六层：
第一层，入口层。
企业微信、飞书、Webhook、定时任务、命令行，都属于入口。入口必须区分来源、用户、群、会话。
第二层，会话层。
私聊和群聊要隔离。不同用户要隔离。不同任务要隔离。临时讨论和长期记忆要隔离。
第三层，权限层。
谁能调用，在哪能调用，能调用什么工具，能不能写文件，能不能外发消息，都要有明确边界。
第四层，工具层。
API、Shell、Playwright、CUA 不是平级工具。它们的风险不同，默认权限也应该不同。
第五层，执行层。
delegate_task 适合短任务分派。Kanban 这类持久任务队列更适合中断恢复和多阶段协作。不要把一次性分派当成长期工作流。
第六层，观测层。
日志、错误、消息来源、工具调用、人工确认、失败样本，都要能追踪。否则一旦出问题，你只能靠猜。
这六层想清楚以后，Agent 才有资格进入真实工作流。
否则它只是一个很聪明、但边界很模糊的机器人。
聪明不是问题。
边界模糊才是问题。
07｜我的结论
Hermes 真正有意思的地方，不是它能不能回答问题。
而是它开始具备一个长期 Agent 系统的雏形：
有记忆。
有技能。
有 Gateway。
有工具层。
有多 Agent 编排。
有 Kanban 这类持久任务方向。
这些东西加起来，才让它有机会从“聊天工具”变成“个人 AI 工作层”。
但这条路不能只靠热情。
你必须接受一个事实：
Agent 越接近真实工作流，工程治理就越重要。
模型只是其中一层。
Gateway、权限、会话、工具、日志、回滚，才决定它能不能长期用。
所以我现在对 Hermes 的态度是：
不吹，不黑。
它值得继续投入，但不能当魔法。
先把它当一个工程系统。
再谈什么 AI 伙伴。
这里是 KevinAIStack。
我会继续记录两条线：
一条给新手看：AI 工具怎么真正进入日常。
一条给技术人看：Agent、Computer Use、本地部署和 Personal AI Stack 到底怎么搭。
先把边界搭好。
再让 Agent 干活。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～
