1. 三层智能体技术体系的整体设计思路1.1 为什么是“三层”而不是“一个万能智能体”很多团队做智能体第一反应是搞一个“全能大模型”把所有能力塞进一个提示词里指望它既能聊天、又能查数据、还能调工具、还能记住上下文。我试过这条路在演示阶段很惊艳一到真实业务就崩。原因很简单上下文窗口有限、工具调用容易串味、权限边界模糊、出错后无法定位是哪一层的问题。汇智智能这套体系把智能体拆成三层本质上是在解决“能力分层”和“责任分层”的问题。Hellome、Hzhermes、词元工场这三个名字听起来像三个独立产品但从工程视角看它们更像是同一套智能体能力栈的三个切面交互层、编排层、执行层。每一层只做自己最擅长的事层与层之间通过明确定义的接口通信而不是靠一个巨型提示词硬扛。这种分层思路在业内越来越常见。2026年WAIC上有个共识工业智能体正从概念演示走向工程化落地分水岭就在于“能不能把智能体拆成可维护、可观测、可替换的模块”。一个销售智能体如果既要理解客户意图又要查CRM又要生成报价单还要记住上次沟通记录单层架构几乎不可能稳定运行。三层体系的价值就在这里让每一层都足够薄薄到可以单独测试、单独迭代、单独扩容。1.2 三层各自解决什么问题Hellome这一层我理解它主要承担用户交互与意图理解。用户说一句话它负责判断“这是闲聊、是查询、还是任务指令”然后把结构化后的意图往下传。这一层不需要知道数据库怎么连、API怎么调它只需要把“人话”翻译成“机器能处理的意图对象”。Hzhermes这一层核心是任务编排与工具调度。它拿到意图后决定要调用哪些工具、按什么顺序调、失败了怎么重试、多个工具的结果怎么合并。这一层是智能体的“大脑”但它不是大模型本身而是大模型驱动的调度器。它需要知道有哪些工具可用、每个工具的输入输出格式、以及业务规则约束。词元工场这一层我倾向于把它理解为执行与资源管理层。它负责实际调用外部API、访问数据库、执行代码、管理token消耗和并发控制。这一层最接近传统后端服务强调稳定性、可观测性和资源隔离。三层各司其职任何一层出问题排查范围都能快速收敛。1.3 分层带来的实际收益我拿一个具体场景来说明。假设用户对销售智能体说“帮我查一下上个月华东区销售额然后给张总发个邮件汇总一下。”单层智能体要同时处理意图识别、数据库查询、邮件发送、权限校验、格式生成。任何一步出错你都不知道是提示词写错了、工具参数传错了、还是权限没配好。三层体系下Hellome识别出“查询发送邮件”两个意图Hzhermes编排“先查数据库再调邮件工具”词元工场执行具体SQL和SMTP调用。如果邮件没发出去你只需要检查词元工场的邮件工具配置如果查错了数据检查Hzhermes的编排逻辑如果意图识别错了检查Hellome的提示词。排查路径从“大海捞针”变成“按层定位”这是分层最大的工程价值。2. Hellome层交互与意图理解的核心细节2.1 意图识别不是分类问题是结构化问题很多人把意图识别当成文本分类来做训练一个模型判断“这是查询类还是指令类”。但在真实业务里用户一句话往往包含多个意图、多个实体、多个约束条件。Hellome这一层如果只做粗分类往下传的信息量根本不够。我的做法是把意图识别做成结构化抽取。用户说“帮我查一下上个月华东区销售额然后给张总发个邮件汇总一下”Hellome输出的不是一个标签而是一个JSON对象{ intents: [ { type: query, target: sales_amount, filters: { region: 华东, time_range: last_month } }, { type: send_email, recipient: 张总, content_source: query_result, format: summary } ], dependencies: [ {from: 0, to: 1, data: query_result} ] }这个结构往下传Hzhermes拿到后就知道先执行第0个意图把结果作为第1个意图的输入。依赖关系显式化编排层不需要猜。2.2 多轮对话的状态管理Hellome还要处理多轮对话。用户第一句说“查一下华东区销售额”第二句说“再查一下华南区的”。如果Hellome不记住上一轮的上下文第二句就会被当成一个独立的、不完整的查询。我的经验是状态管理不要放在大模型里要放在外部存储里。Hellome维护一个会话状态对象包含最近N轮的意图结构、实体值、以及未完成的槽位。每轮新输入进来先和状态对象合并再送给大模型做增量理解。这样即使用户跳转话题再跳回来状态也不会丢。注意状态对象不要无限增长。我一般设置最近10轮或最近5分钟的有效期超期自动清理。否则上下文越来越长延迟和成本都会失控。2.3 提示词设计的几个坑Hellome的提示词我踩过不少坑说几个典型的第一不要用“你是一个智能助手”这种泛化角色。角色越泛模型越容易自由发挥。我一般写成“你是一个意图解析器只输出JSON不输出任何解释性文字”。约束越具体输出越稳定。第二少样本示例要覆盖边界情况。比如用户说“算了不用了”这算取消意图还是闲聊示例里必须包含这类边界否则模型会瞎猜。第三输出格式校验必须做。大模型输出JSON偶尔会多一个逗号、少一个引号。Hellome层必须加一道JSON schema校验校验失败就重试或降级到规则匹配。不要指望模型100%听话。3. Hzhermes层任务编排与工具调度的实现要点3.1 编排引擎的选型逻辑Hzhermes这一层本质上是一个带状态的编排引擎。我对比过几种方案方案优点缺点适用场景纯提示词编排开发快无需额外组件不可观测难调试并发差原型验证有限状态机状态清晰可测试灵活性差新增工具要改代码流程固定的业务图编排引擎灵活支持条件分支和循环学习成本高需要可视化工具复杂多步任务代码即编排最灵活版本可控非技术人员无法参与工程团队主导Hzhermes我倾向于用图编排引擎的思路把每个工具调用定义为一个节点节点之间的边表示数据依赖和条件分支。这样既保留了灵活性又能可视化整个执行路径。Dify这类平台本质上也是这个思路只是封装程度不同。3.2 工具注册与参数映射Hzhermes要调度工具首先得知道有哪些工具可用。我一般维护一个工具注册表每个工具包含名称、描述、输入参数schema、输出schema、超时时间、重试策略、权限要求。tool_registry { query_sales_db: { description: 查询销售数据库, input_schema: { region: {type: string, required: True}, time_range: {type: string, required: True} }, output_schema: { amount: {type: number}, currency: {type: string} }, timeout: 10, retry: 2, permission: sales_read } }当Hzhermes决定调用某个工具时它需要把Hellome传来的意图对象映射成工具的实际参数。这个映射过程我建议用规则模型混合简单参数用规则直接填复杂参数让模型生成生成后再用schema校验。3.3 失败重试与降级策略工具调用失败是常态不是异常。网络抖动、API限流、数据库锁表都会导致失败。Hzhermes必须有一套完整的失败处理策略瞬时失败重试2-3次指数退避。比如第一次等1秒第二次等2秒第三次等4秒。参数错误不重试直接返回错误给上层让Hellome重新理解用户意图。权限不足不重试记录审计日志返回明确的权限提示。超时根据工具类型决定。查询类可以重试写入类不能盲目重试否则可能重复写入。实操心得写入类工具一定要做幂等设计。我一般要求每个写入工具接受一个idempotency_key同一个key重复调用只执行一次。这个key由Hzhermes在编排时生成贯穿整个任务生命周期。3.4 多工具结果的合并与冲突处理一个任务可能调用多个工具结果需要合并。比如查了华东区和华南区的销售额要合并成一个总表。Hzhermes需要定义合并规则是简单拼接、按字段join、还是做聚合计算。冲突处理更麻烦。比如两个工具返回了同一个字段的不同值信谁我的做法是在工具注册表里定义优先级高优先级的工具结果覆盖低优先级的。同时记录冲突日志方便后续排查数据源问题。4. 词元工场层执行与资源管理的落地细节4.1 Token消耗的监控与优化词元工场这个名字本身就暗示了它对token的关注。智能体运行成本的大头就是token消耗尤其是Hellome和Hzhermes两层的大模型调用。词元工场需要做几件事第一按任务、按用户、按工具维度统计token消耗。我一般会在每次大模型调用后记录输入token数、输出token数、模型名称、调用时间、关联任务ID。这些数据汇总后能看出哪些任务最烧钱、哪些提示词最冗长。第二设置预算和熔断。每个用户或每个任务可以设置token预算超预算自动降级到更便宜的模型或者直接终止并提示。我见过太多团队因为没做预算控制一个月token费用超预期十倍。第三缓存重复调用。很多查询类任务同样的参数短时间内重复调用结果是一样的。词元工场可以加一层结果缓存命中缓存直接返回不消耗token。缓存key用工具名参数哈希TTL根据业务特点设置。4.2 并发控制与资源隔离多个智能体任务同时运行时词元工场要防止资源争抢。我一般做两级隔离用户级隔离每个用户有独立的并发配额防止单个用户占满资源。工具级隔离每个工具有独立的连接池和并发上限防止某个慢工具拖垮整个系统。并发控制的实现可以用信号量或令牌桶。我倾向于用令牌桶因为可以平滑限流而不是硬性拒绝。比如数据库查询工具限制每秒10次超出后排队等待而不是直接报错。4.3 可观测性建设词元工场是三层里最接近传统后端的一层可观测性建设可以直接复用后端那套日志、指标、链路追踪。日志每次工具调用记录请求参数、响应结果、耗时、状态码。注意脱敏不要把用户敏感数据写进日志。指标工具调用成功率、平均延迟、P99延迟、token消耗速率、缓存命中率。这些指标接入监控面板设置告警阈值。链路追踪一个任务从Hellome到Hzhermes到词元工场生成一个全局trace_id每一层都带上。排查问题时通过trace_id能把整个链路串起来。注意链路追踪的采样率要控制。全量采集对存储压力太大我一般设置10%采样但错误链路100%采集。4.4 安全与权限校验词元工场是实际执行操作的一层安全校验必须在这里做最后一道把关。Hellome和Hzhermes可能被提示词注入攻击绕过但词元工场的权限校验是硬编码的不依赖模型判断。我一般做三层校验用户身份校验确认调用者是谁有没有登录token有没有过期。工具权限校验确认这个用户有没有权限调用这个工具。比如普通销售不能调用财务数据库。数据行级权限确认这个用户能看哪些数据。比如华东区销售只能看华东区数据不能看华南区。行级权限我一般用规则引擎实现规则存在数据库里词元工场执行前先查规则。这样业务人员可以自己配置权限不需要改代码。5. 三层体系的联调与常见问题排查5.1 联调阶段的典型问题三层分开开发时各自都能跑通一联调就各种问题。我遇到最多的几类接口格式不一致。Hellome输出的意图对象Hzhermes期望的字段名不一样。比如Hellome用time_rangeHzhermes用date_range。这种问题靠文档约束不够我一般用契约测试定义好接口schema双方都基于schema生成代码联调时自动校验。超时传递问题。Hellome给Hzhermes设了5秒超时Hzhermes给词元工场设了10秒超时。结果Hellome已经超时返回了词元工场还在执行资源白白浪费。正确的做法是超时逐层递减Hellome 5秒Hzhermes 4秒词元工场 3秒留出缓冲。错误码不统一。Hellome返回INTENT_UNRECOGNIZEDHzhermes返回TOOL_FAILED词元工场返回DB_TIMEOUT。排查时一脸懵。我一般定义一套全局错误码每层只返回标准错误码详细信息放在details字段里。5.2 常见问题速查表现象可能原因排查步骤解决方案意图识别不准提示词约束不够、示例不足检查Hellome输入输出日志补充边界示例加schema校验工具调用参数错误映射规则有误、模型生成偏差对比意图对象和工具入参加参数校验失败时回退到规则映射任务执行超时某层超时设置不合理、工具慢看链路追踪定位慢节点调整超时优化慢工具或加缓存token消耗异常高提示词冗长、重复调用多按任务统计token精简提示词加结果缓存权限校验失败规则配置错误、用户角色变更检查权限规则和用户角色修正规则加审计日志并发任务互相影响资源未隔离、连接池共享看并发指标和资源使用率加用户级和工具级隔离5.3 独家避坑技巧技巧一给每层加“干跑”模式。Hellome可以只输出意图不往下传Hzhermes可以只输出编排计划不实际调用词元工场可以只校验权限不执行。联调时逐层干跑能快速定位是哪层的问题。技巧二用真实用户日志做回归测试。每次修改提示词或编排逻辑拿最近一周的真实用户请求跑一遍回归看意图识别率和任务成功率有没有下降。我一般维护一个500条左右的回归测试集覆盖常见场景和边界情况。技巧三给大模型调用加“熔断开关”。当大模型服务不稳定时Hellome和Hzhermes可以降级到规则匹配模式。虽然效果差一些但至少能保证核心功能可用。熔断开关我一般做成配置项运维可以动态调整。技巧四token消耗按“任务类型”设基线。比如查询类任务平均消耗500 token如果某个任务消耗了5000 token大概率是提示词出了问题或者陷入了循环。设置基线告警能提前发现异常。6. 从三层体系看智能体工程化的关键认知6.1 智能体不是“更聪明的聊天机器人”很多人把智能体理解成“能调工具的聊天机器人”这个认知太浅了。聊天机器人的核心是对话智能体的核心是任务完成。任务完成需要意图理解、任务规划、工具执行、结果校验、异常处理一整条链路。三层体系的价值就是把这条链路拆开每一段都能独立优化。我见过不少团队智能体demo很惊艳一上生产就各种问题。根因往往不是模型不够强而是工程化没做好。模型能力决定上限工程能力决定下限。三层体系是在保下限。6.2 分层不是目的可替换才是三层体系不是为了分层而分层而是为了每一层都可以独立替换。今天用A模型做意图识别明天想换B模型只需要改Hellome层Hzhermes和词元工场不受影响。今天用图编排引擎明天想换成代码编排只需要改Hzhermes层。这种可替换性在快速演进的AI领域特别重要。模型半年一换代工具生态三个月一变如果架构是铁板一块每次升级都是伤筋动骨。分层架构让升级变成局部手术而不是全身换血。6.3 智能体工程师的能力模型从这套三层体系反推智能体工程师需要的能力也是分层的Hellome层能力提示词工程、意图识别、对话状态管理、多轮交互设计。Hzhermes层能力任务编排、工具抽象、失败处理、并发控制。词元工场层能力后端服务、API设计、数据库、可观测性、安全权限。这三层能力很少有一个人全占。所以团队配置上我建议按层分工有人专注意图理解有人专注编排调度有人专注执行引擎。层与层之间用接口契约解耦各自迭代。实操心得招智能体工程师时不要只看会不会写提示词。提示词只是Hellome层的一部分能力。真正难的是Hzhermes层的编排设计和词元工场层的工程稳定性。面试时我一般给一个多步任务场景看候选人怎么拆解、怎么处理失败、怎么设计接口。6.4 后续扩展方向这套三层体系还可以继续往外延展。比如在Hellome前面加一层多渠道接入层统一处理来自网页、APP、企业微信、邮件的输入。在词元工场后面加一层结果后处理层负责格式化输出、多语言翻译、敏感信息过滤。再往深了做可以在Hzhermes层引入多智能体协作。一个复杂任务拆给多个专业智能体每个智能体有自己的Hellome和词元工场Hzhermes负责协调它们之间的通信和结果合并。这就是多智能体系统的雏形。我在实际项目里发现三层体系跑通之后往上加东西比从零搭建容易得多。因为每一层的边界清晰新功能只需要挂到对应的层上不会牵一发动全身。这种可生长性是分层架构最被低估的价值。最后分享一个小技巧如果你刚开始搭智能体不要一上来就搞三层。先用单层跑通一个最小闭环然后遇到什么问题就拆什么层。架构是演化出来的不是设计出来的。我见过太多团队一开始就追求完美分层结果三个月还在画架构图一个能用的功能都没上线。先跑起来再优化这才是工程化的正确姿势。
三层智能体架构实战：Hellome、Hzhermes与词元工场的工程化落地
1. 三层智能体技术体系的整体设计思路1.1 为什么是“三层”而不是“一个万能智能体”很多团队做智能体第一反应是搞一个“全能大模型”把所有能力塞进一个提示词里指望它既能聊天、又能查数据、还能调工具、还能记住上下文。我试过这条路在演示阶段很惊艳一到真实业务就崩。原因很简单上下文窗口有限、工具调用容易串味、权限边界模糊、出错后无法定位是哪一层的问题。汇智智能这套体系把智能体拆成三层本质上是在解决“能力分层”和“责任分层”的问题。Hellome、Hzhermes、词元工场这三个名字听起来像三个独立产品但从工程视角看它们更像是同一套智能体能力栈的三个切面交互层、编排层、执行层。每一层只做自己最擅长的事层与层之间通过明确定义的接口通信而不是靠一个巨型提示词硬扛。这种分层思路在业内越来越常见。2026年WAIC上有个共识工业智能体正从概念演示走向工程化落地分水岭就在于“能不能把智能体拆成可维护、可观测、可替换的模块”。一个销售智能体如果既要理解客户意图又要查CRM又要生成报价单还要记住上次沟通记录单层架构几乎不可能稳定运行。三层体系的价值就在这里让每一层都足够薄薄到可以单独测试、单独迭代、单独扩容。1.2 三层各自解决什么问题Hellome这一层我理解它主要承担用户交互与意图理解。用户说一句话它负责判断“这是闲聊、是查询、还是任务指令”然后把结构化后的意图往下传。这一层不需要知道数据库怎么连、API怎么调它只需要把“人话”翻译成“机器能处理的意图对象”。Hzhermes这一层核心是任务编排与工具调度。它拿到意图后决定要调用哪些工具、按什么顺序调、失败了怎么重试、多个工具的结果怎么合并。这一层是智能体的“大脑”但它不是大模型本身而是大模型驱动的调度器。它需要知道有哪些工具可用、每个工具的输入输出格式、以及业务规则约束。词元工场这一层我倾向于把它理解为执行与资源管理层。它负责实际调用外部API、访问数据库、执行代码、管理token消耗和并发控制。这一层最接近传统后端服务强调稳定性、可观测性和资源隔离。三层各司其职任何一层出问题排查范围都能快速收敛。1.3 分层带来的实际收益我拿一个具体场景来说明。假设用户对销售智能体说“帮我查一下上个月华东区销售额然后给张总发个邮件汇总一下。”单层智能体要同时处理意图识别、数据库查询、邮件发送、权限校验、格式生成。任何一步出错你都不知道是提示词写错了、工具参数传错了、还是权限没配好。三层体系下Hellome识别出“查询发送邮件”两个意图Hzhermes编排“先查数据库再调邮件工具”词元工场执行具体SQL和SMTP调用。如果邮件没发出去你只需要检查词元工场的邮件工具配置如果查错了数据检查Hzhermes的编排逻辑如果意图识别错了检查Hellome的提示词。排查路径从“大海捞针”变成“按层定位”这是分层最大的工程价值。2. Hellome层交互与意图理解的核心细节2.1 意图识别不是分类问题是结构化问题很多人把意图识别当成文本分类来做训练一个模型判断“这是查询类还是指令类”。但在真实业务里用户一句话往往包含多个意图、多个实体、多个约束条件。Hellome这一层如果只做粗分类往下传的信息量根本不够。我的做法是把意图识别做成结构化抽取。用户说“帮我查一下上个月华东区销售额然后给张总发个邮件汇总一下”Hellome输出的不是一个标签而是一个JSON对象{ intents: [ { type: query, target: sales_amount, filters: { region: 华东, time_range: last_month } }, { type: send_email, recipient: 张总, content_source: query_result, format: summary } ], dependencies: [ {from: 0, to: 1, data: query_result} ] }这个结构往下传Hzhermes拿到后就知道先执行第0个意图把结果作为第1个意图的输入。依赖关系显式化编排层不需要猜。2.2 多轮对话的状态管理Hellome还要处理多轮对话。用户第一句说“查一下华东区销售额”第二句说“再查一下华南区的”。如果Hellome不记住上一轮的上下文第二句就会被当成一个独立的、不完整的查询。我的经验是状态管理不要放在大模型里要放在外部存储里。Hellome维护一个会话状态对象包含最近N轮的意图结构、实体值、以及未完成的槽位。每轮新输入进来先和状态对象合并再送给大模型做增量理解。这样即使用户跳转话题再跳回来状态也不会丢。注意状态对象不要无限增长。我一般设置最近10轮或最近5分钟的有效期超期自动清理。否则上下文越来越长延迟和成本都会失控。2.3 提示词设计的几个坑Hellome的提示词我踩过不少坑说几个典型的第一不要用“你是一个智能助手”这种泛化角色。角色越泛模型越容易自由发挥。我一般写成“你是一个意图解析器只输出JSON不输出任何解释性文字”。约束越具体输出越稳定。第二少样本示例要覆盖边界情况。比如用户说“算了不用了”这算取消意图还是闲聊示例里必须包含这类边界否则模型会瞎猜。第三输出格式校验必须做。大模型输出JSON偶尔会多一个逗号、少一个引号。Hellome层必须加一道JSON schema校验校验失败就重试或降级到规则匹配。不要指望模型100%听话。3. Hzhermes层任务编排与工具调度的实现要点3.1 编排引擎的选型逻辑Hzhermes这一层本质上是一个带状态的编排引擎。我对比过几种方案方案优点缺点适用场景纯提示词编排开发快无需额外组件不可观测难调试并发差原型验证有限状态机状态清晰可测试灵活性差新增工具要改代码流程固定的业务图编排引擎灵活支持条件分支和循环学习成本高需要可视化工具复杂多步任务代码即编排最灵活版本可控非技术人员无法参与工程团队主导Hzhermes我倾向于用图编排引擎的思路把每个工具调用定义为一个节点节点之间的边表示数据依赖和条件分支。这样既保留了灵活性又能可视化整个执行路径。Dify这类平台本质上也是这个思路只是封装程度不同。3.2 工具注册与参数映射Hzhermes要调度工具首先得知道有哪些工具可用。我一般维护一个工具注册表每个工具包含名称、描述、输入参数schema、输出schema、超时时间、重试策略、权限要求。tool_registry { query_sales_db: { description: 查询销售数据库, input_schema: { region: {type: string, required: True}, time_range: {type: string, required: True} }, output_schema: { amount: {type: number}, currency: {type: string} }, timeout: 10, retry: 2, permission: sales_read } }当Hzhermes决定调用某个工具时它需要把Hellome传来的意图对象映射成工具的实际参数。这个映射过程我建议用规则模型混合简单参数用规则直接填复杂参数让模型生成生成后再用schema校验。3.3 失败重试与降级策略工具调用失败是常态不是异常。网络抖动、API限流、数据库锁表都会导致失败。Hzhermes必须有一套完整的失败处理策略瞬时失败重试2-3次指数退避。比如第一次等1秒第二次等2秒第三次等4秒。参数错误不重试直接返回错误给上层让Hellome重新理解用户意图。权限不足不重试记录审计日志返回明确的权限提示。超时根据工具类型决定。查询类可以重试写入类不能盲目重试否则可能重复写入。实操心得写入类工具一定要做幂等设计。我一般要求每个写入工具接受一个idempotency_key同一个key重复调用只执行一次。这个key由Hzhermes在编排时生成贯穿整个任务生命周期。3.4 多工具结果的合并与冲突处理一个任务可能调用多个工具结果需要合并。比如查了华东区和华南区的销售额要合并成一个总表。Hzhermes需要定义合并规则是简单拼接、按字段join、还是做聚合计算。冲突处理更麻烦。比如两个工具返回了同一个字段的不同值信谁我的做法是在工具注册表里定义优先级高优先级的工具结果覆盖低优先级的。同时记录冲突日志方便后续排查数据源问题。4. 词元工场层执行与资源管理的落地细节4.1 Token消耗的监控与优化词元工场这个名字本身就暗示了它对token的关注。智能体运行成本的大头就是token消耗尤其是Hellome和Hzhermes两层的大模型调用。词元工场需要做几件事第一按任务、按用户、按工具维度统计token消耗。我一般会在每次大模型调用后记录输入token数、输出token数、模型名称、调用时间、关联任务ID。这些数据汇总后能看出哪些任务最烧钱、哪些提示词最冗长。第二设置预算和熔断。每个用户或每个任务可以设置token预算超预算自动降级到更便宜的模型或者直接终止并提示。我见过太多团队因为没做预算控制一个月token费用超预期十倍。第三缓存重复调用。很多查询类任务同样的参数短时间内重复调用结果是一样的。词元工场可以加一层结果缓存命中缓存直接返回不消耗token。缓存key用工具名参数哈希TTL根据业务特点设置。4.2 并发控制与资源隔离多个智能体任务同时运行时词元工场要防止资源争抢。我一般做两级隔离用户级隔离每个用户有独立的并发配额防止单个用户占满资源。工具级隔离每个工具有独立的连接池和并发上限防止某个慢工具拖垮整个系统。并发控制的实现可以用信号量或令牌桶。我倾向于用令牌桶因为可以平滑限流而不是硬性拒绝。比如数据库查询工具限制每秒10次超出后排队等待而不是直接报错。4.3 可观测性建设词元工场是三层里最接近传统后端的一层可观测性建设可以直接复用后端那套日志、指标、链路追踪。日志每次工具调用记录请求参数、响应结果、耗时、状态码。注意脱敏不要把用户敏感数据写进日志。指标工具调用成功率、平均延迟、P99延迟、token消耗速率、缓存命中率。这些指标接入监控面板设置告警阈值。链路追踪一个任务从Hellome到Hzhermes到词元工场生成一个全局trace_id每一层都带上。排查问题时通过trace_id能把整个链路串起来。注意链路追踪的采样率要控制。全量采集对存储压力太大我一般设置10%采样但错误链路100%采集。4.4 安全与权限校验词元工场是实际执行操作的一层安全校验必须在这里做最后一道把关。Hellome和Hzhermes可能被提示词注入攻击绕过但词元工场的权限校验是硬编码的不依赖模型判断。我一般做三层校验用户身份校验确认调用者是谁有没有登录token有没有过期。工具权限校验确认这个用户有没有权限调用这个工具。比如普通销售不能调用财务数据库。数据行级权限确认这个用户能看哪些数据。比如华东区销售只能看华东区数据不能看华南区。行级权限我一般用规则引擎实现规则存在数据库里词元工场执行前先查规则。这样业务人员可以自己配置权限不需要改代码。5. 三层体系的联调与常见问题排查5.1 联调阶段的典型问题三层分开开发时各自都能跑通一联调就各种问题。我遇到最多的几类接口格式不一致。Hellome输出的意图对象Hzhermes期望的字段名不一样。比如Hellome用time_rangeHzhermes用date_range。这种问题靠文档约束不够我一般用契约测试定义好接口schema双方都基于schema生成代码联调时自动校验。超时传递问题。Hellome给Hzhermes设了5秒超时Hzhermes给词元工场设了10秒超时。结果Hellome已经超时返回了词元工场还在执行资源白白浪费。正确的做法是超时逐层递减Hellome 5秒Hzhermes 4秒词元工场 3秒留出缓冲。错误码不统一。Hellome返回INTENT_UNRECOGNIZEDHzhermes返回TOOL_FAILED词元工场返回DB_TIMEOUT。排查时一脸懵。我一般定义一套全局错误码每层只返回标准错误码详细信息放在details字段里。5.2 常见问题速查表现象可能原因排查步骤解决方案意图识别不准提示词约束不够、示例不足检查Hellome输入输出日志补充边界示例加schema校验工具调用参数错误映射规则有误、模型生成偏差对比意图对象和工具入参加参数校验失败时回退到规则映射任务执行超时某层超时设置不合理、工具慢看链路追踪定位慢节点调整超时优化慢工具或加缓存token消耗异常高提示词冗长、重复调用多按任务统计token精简提示词加结果缓存权限校验失败规则配置错误、用户角色变更检查权限规则和用户角色修正规则加审计日志并发任务互相影响资源未隔离、连接池共享看并发指标和资源使用率加用户级和工具级隔离5.3 独家避坑技巧技巧一给每层加“干跑”模式。Hellome可以只输出意图不往下传Hzhermes可以只输出编排计划不实际调用词元工场可以只校验权限不执行。联调时逐层干跑能快速定位是哪层的问题。技巧二用真实用户日志做回归测试。每次修改提示词或编排逻辑拿最近一周的真实用户请求跑一遍回归看意图识别率和任务成功率有没有下降。我一般维护一个500条左右的回归测试集覆盖常见场景和边界情况。技巧三给大模型调用加“熔断开关”。当大模型服务不稳定时Hellome和Hzhermes可以降级到规则匹配模式。虽然效果差一些但至少能保证核心功能可用。熔断开关我一般做成配置项运维可以动态调整。技巧四token消耗按“任务类型”设基线。比如查询类任务平均消耗500 token如果某个任务消耗了5000 token大概率是提示词出了问题或者陷入了循环。设置基线告警能提前发现异常。6. 从三层体系看智能体工程化的关键认知6.1 智能体不是“更聪明的聊天机器人”很多人把智能体理解成“能调工具的聊天机器人”这个认知太浅了。聊天机器人的核心是对话智能体的核心是任务完成。任务完成需要意图理解、任务规划、工具执行、结果校验、异常处理一整条链路。三层体系的价值就是把这条链路拆开每一段都能独立优化。我见过不少团队智能体demo很惊艳一上生产就各种问题。根因往往不是模型不够强而是工程化没做好。模型能力决定上限工程能力决定下限。三层体系是在保下限。6.2 分层不是目的可替换才是三层体系不是为了分层而分层而是为了每一层都可以独立替换。今天用A模型做意图识别明天想换B模型只需要改Hellome层Hzhermes和词元工场不受影响。今天用图编排引擎明天想换成代码编排只需要改Hzhermes层。这种可替换性在快速演进的AI领域特别重要。模型半年一换代工具生态三个月一变如果架构是铁板一块每次升级都是伤筋动骨。分层架构让升级变成局部手术而不是全身换血。6.3 智能体工程师的能力模型从这套三层体系反推智能体工程师需要的能力也是分层的Hellome层能力提示词工程、意图识别、对话状态管理、多轮交互设计。Hzhermes层能力任务编排、工具抽象、失败处理、并发控制。词元工场层能力后端服务、API设计、数据库、可观测性、安全权限。这三层能力很少有一个人全占。所以团队配置上我建议按层分工有人专注意图理解有人专注编排调度有人专注执行引擎。层与层之间用接口契约解耦各自迭代。实操心得招智能体工程师时不要只看会不会写提示词。提示词只是Hellome层的一部分能力。真正难的是Hzhermes层的编排设计和词元工场层的工程稳定性。面试时我一般给一个多步任务场景看候选人怎么拆解、怎么处理失败、怎么设计接口。6.4 后续扩展方向这套三层体系还可以继续往外延展。比如在Hellome前面加一层多渠道接入层统一处理来自网页、APP、企业微信、邮件的输入。在词元工场后面加一层结果后处理层负责格式化输出、多语言翻译、敏感信息过滤。再往深了做可以在Hzhermes层引入多智能体协作。一个复杂任务拆给多个专业智能体每个智能体有自己的Hellome和词元工场Hzhermes负责协调它们之间的通信和结果合并。这就是多智能体系统的雏形。我在实际项目里发现三层体系跑通之后往上加东西比从零搭建容易得多。因为每一层的边界清晰新功能只需要挂到对应的层上不会牵一发动全身。这种可生长性是分层架构最被低估的价值。最后分享一个小技巧如果你刚开始搭智能体不要一上来就搞三层。先用单层跑通一个最小闭环然后遇到什么问题就拆什么层。架构是演化出来的不是设计出来的。我见过太多团队一开始就追求完美分层结果三个月还在画架构图一个能用的功能都没上线。先跑起来再优化这才是工程化的正确姿势。
