本体驱动ERP｜47个Agent，26个是幽灵：你的公司是不是也成了Agent垃圾场？

去年帮一家做供应链的公司做 Agent 盘点，47 个里 26 个是"幽灵"。

还在跑，还占着 GPU，但没人知道它在干嘛、有没有人在用。最狠的一个，三个月前接口就调不通了，下游三个 Agent 照调不误，吐了一整季的错数据，等发现时月结已经错两轮了。

老板问我："我们不是在做 AI 吗，怎么做成垃圾场了？"

我没法反驳。Agent 这两年从"概念"变成"标配"，每个部门都搞一个，搞完就扔那。等数量过 20，管理成本就开始反超开发成本。这事我见过太多次了，今天把它讲透。

我见过的四种死法

死法一：幽灵 Agent 白烧钱

盘那家公司时，47 个里只有 21 个还在被真实调用，剩下 26 个全是"幽灵"，还占着算力，但输入输出没人说得清，有没有人用也没人知道。你不敢停，怕停了哪个业务线突然炸；也不敢动，怕动了牵出更深的坑。最狠的那个幽灵，静默失败吐错数据，月结错两轮才被发现。

死法二：功能重复到离谱

市场部有个"竞品分析 Agent"，战略部有个"对手监测 Agent"，产品部有个"行业扫描 Agent"——干的事八成重叠，各自调各自的 API，各自存各自的结果。三个 Agent 一个月花掉的 token 费，加起来够建一个做得更好的。钱不是问题，问题是谁都不觉得自己在重复。

死法三：调用链一团浆糊

Agent A 调 B，B 又调 C，C 的输出被 D 消费。出了问题想排查，得顺着调用链一层层找，比微服务的依赖链还乱。我见过一个 Agent 改了输出格式，下游三个 Agent 全挂，几个人排查了一下午，最后发现根因在没人记得的那个节点。

死法四：权限和安全裸奔

每个 Agent 各自配各自的 API Key 和数据库权限，没人统一管。有的 Agent 拿了全库读写权限，却只用来做查询。你问安全团队这些 Agent 都有什么权限，他们两眼一黑——不知道。这不是疏忽，是根本没有"谁有权"这张表。

先泼盆冷水：你真需要这么多 Agent 吗

看到这你可能觉得：赶紧上注册中心，把 47 个管起来。但我得先泼盆冷水——注册中心不是让你继续囤 Agent 的借口，它的第一个作用，是帮你发现该砍哪些。

那家供应链公司盘完，我第一反应也是"你们太乱了得有个中心"。但冷静下来想，47 个里真正高频用的就十来个，剩下大半是某个周末 PoC 跑通了就忘了下线。问题不是"管不住"，是"根本不该生出来"。

所以先回答你心里的疑问：什么时候才真的需要多个 Agent？

1. 单 Agent 撞墙时。一个对话装不下所有上下文（邮件历史 + 日历 + 工单 + CRM 全塞进去，质量直线掉）；或者它在"查资料、写代码、改文案"之间反复横跳，每样都做不精；或者任务天然要并行（同时调研 10 个竞品），一个 Agent 只能串行干等。

2. 要故障隔离时。一个环节挂了，不想拖垮整条线。拆成独立 Agent，挂的就挂，别的照跑。

3. 要成本分层时。分诊用便宜模型，综合用强模型。一个 Agent 没法"便宜和贵自己切"。

反过来，什么情况根本不需要多 Agent：一个边界清晰、工具齐备的单 Agent 能干掉 80% 的需求。我见过团队把"合同审查""条款比对""风险标注"拆成三个 Agent，其实就是一个 Agent + 三个工具的事。拆完不仅没快，还多了一堆要协调的接口。

一句话：建得多不是能力，管得住才是。注册中心先帮你做减法，再帮你做加法。

你现在的 Agent 世界，大概长这样：

现在的 Agent 世界市场部Agent战略部Agent客服Agent幽灵Agent?没人管权限裸奔调用链无人知有注册中心之后Agent注册中心市场部战略部客服审批运维监控安全审计本体库受控可追踪你差的，就是这一步

图：左是现在的 Agent 世界（乱调、裸奔、无人知），右是挂了注册中心之后（统一收口、可追踪、受控）

微服务那套为啥不够

看到这，搞过微服务的兄弟会说：不就是 Eureka / Nacos 换皮吗？我还真研究过，不一样。微服务注册的是"地址"，Agent 注册的是"能力"。

微服务时代，服务 A 调 B 是代码里写死的，调某个接口，传 JSON，拿 JSON，参数和签名都固定，调用方被调用方强耦合。Agent 不一样：Agent A 让 B 帮忙，说的是自然语言意图，不是 API 调用；B 可能用不同方式响应，返回也不是固定 schema。这个"意图 → 能力匹配 → 路由 → 执行"的过程，微服务注册中心根本搞不定。

注册中心到底管哪四件事

说白了，它就是 Agent 的"户籍系统"。每个 Agent 上线前先来登记，下线前先注销，调别人先来查地址。具体四件事：

1. 注册与发现。上线时声明自己叫什么、能干什么、输入输出是什么、在哪能找到。别硬编码地址，查注册中心就行。

2. 能力目录。按业务域分类，列出所有 Agent 的能力。新需求来了先查目录，有没有现成能力能复用——这一步是灭掉"功能重复建设"的关键。

3. 调用链追踪。谁调了谁、什么时候调的、传了什么、返回了什么，全记下来。出问题能快速定位是哪个环节断的，而不是排查一下午。

4. 权限与策略管理。统一管理访问权限、调用频率、资源配额。谁能调谁、一次调多少、超时怎么办，都在这配——权限裸奔这事就从源头堵了。

能力描述写差了，等于白注册

注册中心最核心的不是路由，是能力描述怎么写。写差了，Agent 搜不到，等于没注册。

我见过大多数团队的做法是写一句话："这个 Agent 做合同审查"。这跟没写差不多。市场部的"竞品分析"和战略部的"对手监测"都写一句话，你根本看不出来它俩重复了。

我的经验是分三层写：

{   "agent_id": "contract-review-v2",   "name": "合同条款审查 Agent",   "domain": "法务",   "capability": {     "intent": "审查合同条款的合规性和风险",     "input_schema": {       "contract_text": "string, 合同全文",       "review_focus": "enum[风险条款, 合规检查, 商务条件]"     },     "output_schema": {       "risk_items": "list[RiskItem]",       "compliance_status": "enum[通过, 需修改, 不通过]",       "suggestions": "list[string]"     }   },   "dependencies": ["合同条款本体", "合规规则库"],   "version": "2.1.0",   "cost_per_call": "0.8 元",   "avg_latency": "3.2s" }

第一层是意图（intent），说清干什么；第二层是输入输出 schema，让调用方知道传什么、拿什么；第三层是依赖和元数据——依赖哪些本体和知识库，每次调用多少钱、平均多快返回。

这样写的最大好处：新需求来了，拿意图去注册中心搜，看有没有现成能力。"我要查合同风险"和"审查合同条款的合规性和风险"能匹配上，重复建设就暴露了。

多 Agent 架构到底解决什么问题

有人会问：搞这么多 Agent，图啥？我给你一个不绕的答案——分而治之。把一个又大又模糊的任务，切成几块小而可验证的活，每块交给一个专才，最后由协调者拼起来。

它真正换来的就五样：

专业化。每个 Agent 只盯一件事，比一个啥都干点的通用 Agent 做得深。 并行。多块活同时跑，墙钟时间砍半。 上下文隔离。各管各的专注上下文，互不污染——不会因为前面聊了代码，后面写文案也带着代码味。 故障隔离。一个挂了别的照跑，不像单 Agent 一卡全停。 成本分层。分诊甩给便宜模型，综合留给强模型。

但有个坑得说在前头：多 Agent 引入了协调成本。你是用"一个 Agent 啥都做不精"换了"N 个 Agent 要接、要盯、要调"。协调不好，就是本文开头的四种死法，而且来得更快。

所以多 Agent 是手段不是目的。目的只有一个：问题大到或并行到单 Agent 扛不住。如果你说不出一句话"为什么 B 要把活交给 C"，那你是为拆而拆，纯添乱。

本体在这里能解决什么

上面说的注册中心，如果背后没有本体，说白了就是个电话簿：它知道谁叫啥、在哪，但不知道谁到底能干啥、谁跟谁其实在干同一件事。

挂上本体，它才变成一层推理层。具体四件事：

1. 统一能力语义。所有 Agent 的能力用同一套词描述——能力类型 × 业务对象 × 操作维度。不再是各写各的一句话。 2. 确定性意图匹配。意图到能力的映射走公理，不是 embedding 靠运气碰。 3. 重复一眼可见。重叠的能力变成结构化标签，撞车当场暴露。 4. 约束可定义。哪个 Agent 能干啥、依赖谁，写成 OWL 公理，推理机逐条校验——这正好是给 Agent 套"缰绳"的那层（受控专精的核心）。

注册中心（无本体）= 电话簿Agent A：做合同审查Agent B：协议风险扫描Agent C：竞品分析看不出重复 · 搜不准注册中心（有本体）= 推理层[审查 × 合同 × 合规][审查 × 合同 × 风险][分析 × 竞品 × 效率]重复可见 · 确定性匹配

图：没有本体的注册中心只是电话簿（记名字），有本体才变成能推理、能查重的语义层

一句话：本体是把一堆 Agent 粘成一个舰队的那层胶水。没有它，注册中心只是把混乱规模化了。下面是我踩过的真实匹配坑，正好印证这点。

我踩过的匹配坑：本体不是来打广告的

我得说实话，能力匹配这块我踩过坑。一开始我也用关键词 + 向量做，"合同条款审查"和"协议风险扫描"明明是同一件事，关键词对不上，向量相似度也不高，死活匹配不到一块。

后来我在注册中心背后挂了个能力本体，这俩才被识别成同一件事。本体干的活，是把所有 Agent 的能力用统一语义模型描述出来：

能力类型：审查 / 分析 / 生成 / 检索 / 审批 / 通知 业务对象：合同 / 订单 / 客户 / 竞品 / 数据 / 工单 操作维度：合规 / 风险 / 效率 / 质量 / 成本

"合同条款审查"在这个模型里是 [审查 × 合同 × 合规+风险]。"协议风险扫描"是 [审查 × 合同 × 风险]——同一个能力类型、同一个业务对象，重叠度一眼看出来。"竞品分析"和"对手监测"都是 [分析 × 竞品 × 效率]，完完全全重复。

没有本体的注册中心，能力目录是一堆文字描述，搜不准也比对不了。有了本体，能力变成了结构化标签，重复建设一眼可见，意图匹配精度翻倍。

两个真玩家的策略：OpenClaw 与 Hermes-agent

光讲道理虚。给你看两个真实项目怎么落这套"舰队纪律"的——它们都不叫"注册中心"，但干的活一模一样：把一堆 Agent 管得可追溯、可控、可验证。

OpenClaw：编排器 + 协议 + 权限冒泡。它的模型是一个 Orchestrator 把目标拆了，spawn 一群子 Agent 并行干，干完汇报，它来汇总。几个招牌动作：

① ACP 协议（Agent Communication Protocol）：每次 Agent 间传话都是结构化消息——sender / receiver / task_type / priority / context / payload / deadline / callback。这玩意儿本质就是"流动中的注册表条目"，每次交接都有迹可循，不是靠默契。 ② Permission Bubbling（权限冒泡）：子 Agent 要做超出自己权限范围的事，它先暂停、上报编排器，而不是自己擅自动手。这正好治"权限裸奔"。 ③ 路由集中在一处（openclaw.json），每个 worker 工作区窄、交接小到可审计；还有个可选的 Critic Agent，合并前先审一遍输出。

它自己也在警告：别早早强上 swarm 复杂度，先把单 Agent 稳住；你要是说不清 B 为啥交给 C，就是碎过头了。

Hermes-agent：枢纽辐射 + 看板 + 可验证交接。主 Agent 是枢纽，用 delegate_task 派生出"一次性"子 Agent（各自独立的上下文、终端、工具、预算）。招牌动作：

① Kanban 多 Agent（v0.12+）：任务摊在一块共享看板上，每个 Agent 是个独立进程去"认领"，认领是原子事务；崩了探测到就回收重派，连挂三次触发熔断转人工。这块看板，本质就是个"工作注册表"。 ② 可验证交接：子 Agent 交差不能只说"我搞定了"，必须甩出路径 / diff / 测试结果 / 截图 / URL / 看板任务号。这正好是治"幽灵 / 裸奔"的解药。 ③ 角色隔离 + 工具边界：研究员绝不碰生产代码，审核员绝不批自己写的活。

它的哲学就一句："不是加更多 Agent，而是把角色切干净、产物可验证、交接看得见。"

你发现没，不管叫注册中心、ACP 还是看板，纪律是同一套：拓扑显式、权限收口、交接可验证、全程可审计。而上一节说的本体，就是让 ACP / 看板里那个"能力"字段从自由文本变成有语义的标签——不然你记了一堆名字，还是不知道谁跟谁重复。

我推荐的四步落地法

别一上来就从零写。我给那家供应链公司走的是一条务实路线，四个开源组件拼起来：

第一步，API 网关做底座。APISIX 或 Kong 都行，先把 Agent 调用统一收口。这一步解的是"权限裸奔"和"调用链不可追踪"。

第二步，加能力目录服务。基于开源 Service Catalog 改，把"服务"换成"能力描述"，每个 Agent 上线就往这注册。这一步解的是"幽灵 Agent"和"重复建设"。

第三步，接轻量本体。用 Protégé 建一个能力分类本体，定义能力类型、业务对象、操作维度的概念体系，给每个 Agent 打标签。这一步解的是"意图匹配搜不准"。

第四步，加链路追踪。用 OpenTelemetry 给每次 Agent 调用打 trace，跨 Agent 调用全串起来。这一步解的是"调用链一团浆糊"。

盘完那家公司，我们顺着目录下线了 26 个幽灵 Agent，每月 GPU 账单直接少了一万二；故障定位时间从一下午缩到 10 分钟。四步走完，你就有了一个真能用的注册中心，没自己造半行轮子。

诚实地说局限

注册中心不是银弹，有三件事我得跟你说清楚，免得你上来就迷信：

1. 本体和目录要人维护。小团队别上来就建本体，先用一张表或 Notion 记清楚"谁有什么能力"，等 Agent 过 20 个再上系统。过早上重武器，维护成本比收益还高。

2. 隐式依赖抽不出来。很多 Agent 的依赖写在 prompt 里——"记得先调 XX 再调我"。这种暗线注册中心管不了，它只认你显式登记的东西。

3. 上了中心不报警照样翻车。注册中心是地图，不是交警。它标记了"这是个幽灵"，你不处理，它还是在那白烧 GPU。治理是持续的活，不是装好就完事。

等 Agent 多到管不过来才搭系统，就像等房间堆满垃圾才买垃圾桶。晚了，味儿已经散不掉。

你们公司有没有那种"不敢停、也不敢动、也没人知道干嘛"的幽灵 Agent？

评论区报一下它的名字，我看能集齐多少个。也说说它是哪个部门的——我赌十块钱是财务或者法务那边的。