1. 项目概述从“agency-agents”这个词组看智能体系统的设计本质“agency-agents”不是某个具体软件、平台或开源库的官方名称而是一个高度凝练的复合概念词——它把“agency”能动性、自主性、目标导向的行为能力和“agents”智能体、代理、可执行单元两个核心术语强行焊接在一起。我在过去三年里参与过多个跨团队协作的智能体系统搭建项目从某高校实验室的多智能体仿真平台到某公司内部的自动化流程编排系统再到面向中小企业的轻量级任务调度工具链反复遇到一个共性问题开发者总在“让智能体干活”和“让智能体像人一样思考”之间反复横跳最后交付的系统要么是功能堆砌的“命令行集合”要么是逻辑空转的“哲学玩具”。而“agency-agents”这个词恰恰戳中了这个断层带的中心。它不是一个技术名词而是一面镜子照出当前智能体开发中最容易被忽略的底层契约智能体必须同时具备“agent”的结构可操作性和“agency”的行为合理性。前者意味着它得有明确的输入/输出接口、可配置的执行策略、可观测的状态机后者意味着它不能只响应指令还得理解上下文、权衡优先级、主动发起动作、在信息不全时做出合理推断。比如一个只负责“把邮件发给张三”的智能体是agent但一个能判断“当前是下班时间张三可能已离线先存草稿并设置明早9点自动发送同时向我推送提醒”的智能体才开始具备agency。这个词组背后真正的需求是解决“自动化”与“智能化”的撕裂感。很多团队买了RPA工具写了一堆脚本结果发现90%的流程卡在“需要人工判断下一步该做什么”这个环节另一些团队上了大模型API让LLM生成指令又发现生成的指令根本没法被下游系统执行——因为LLM输出的是自然语言而系统要的是结构化参数。agency-agents的本质就是在这两者之间架一座双向翻译桥上承语义意图下接原子能力中间用可验证、可调试、可组合的规则来锚定行为边界。所以如果你看到这个词出现在技术讨论、招聘JD或架构文档里它大概率不是在说“又一个新框架”而是在宣告一种设计范式的转向不再把智能体当黑盒调用而是把它当作一个拥有“数字人格”的协作伙伴来建模。它适合正在从单点自动化迈向流程自治的工程师、正在设计AI原生应用的产品负责人以及所有被“LLM很聪明但总干不了实事”这个问题困扰的技术决策者。接下来的内容我会完全基于这个认知前提拆解如何真正落地一个具备agency的agents系统——不讲虚概念只讲你明天就能动手改的配置、能立刻验证的逻辑、以及踩过坑后才懂的取舍。2. 核心设计思路为什么必须放弃“智能体即函数”的旧范式2.1 传统Agent模型的三大结构性缺陷在我参与的某跨平台系统重构项目中团队最初沿用了主流做法把每个智能体封装成一个Python函数输入是JSON字典输出是另一个JSON字典中间调用LLM API做推理。运行两周后我们遇到了三个无法绕开的硬伤最终推倒重来状态不可见函数是无状态的。每次调用都像重启一次大脑无法记住“上一步我查了订单号这一步该去查物流”更别说“用户连续三次问同一问题说明ta没看懂该换种解释方式”。我们曾试图用Redis缓存会话ID步骤索引但很快发现当多个智能体协同工作时状态散落在不同服务、不同数据库里调试时要开七八个终端窗口查日志平均定位一个超时问题要47分钟。意图不可溯LLM输出的文本指令比如“请更新客户A的合同到期日为2025年6月30日”看似明确实则埋着雷。它没说明依据哪份邮件附件、是否已获得法务确认、是否需要同步通知销售主管。当执行失败时你只能看到“更新失败”却不知道失败是因为权限不足、字段格式错误还是上游数据源未就绪。我们试过让LLM在输出里加JSON Schema校验结果发现模型在压力下会“幻觉”出不存在的字段名导致整个解析链路崩溃。责任不可分当一个复杂任务如“处理客户投诉并升级”由5个智能体接力完成时如果最终结果出错你无法快速判断是第2步的意图解析错了还是第4步的权限校验漏了抑或是第3步调用外部API时网络抖动。传统函数式模型把所有逻辑压在一个run()方法里等于把责任全部打包塞进一个黑箱违背了工程领域最基础的“单一职责”原则。提示这三个缺陷不是实现问题而是范式问题。就像用面向过程的方式写大型Web应用再怎么优化函数也解决不了模块耦合度高的根本矛盾。2.2 agency-agents的四层架构把“能动性”变成可配置的组件我们最终采用的方案是把agency拆解为四个正交的、可独立配置和替换的模块形成一个分层架构。这不是理论设计而是从生产环境血泪教训里长出来的意图层Intention Layer负责接收原始输入用户消息、系统事件、定时触发将其转化为结构化的“意图声明”。关键不是让LLM直接生成动作而是先生成一个带元信息的意图对象例如{ intent_id: INT-2024-0876, action: update_contract_expiry, target: {customer_id: CUST-8821, contract_id: CT-9932}, context: {source: email_thread_4455, urgency: high, compliance_required: true}, confidence: 0.92 }这个对象本身可存入数据库成为所有后续操作的“唯一事实源”。我们用微调后的轻量级分类模型做初筛再用大模型做细粒度解析准确率从73%提升到96%且每次解析失败都能回溯到具体哪个字段置信度低于阈值。规划层Planning Layer根据意图声明动态生成可执行的“步骤序列”。它不直接调用API而是输出一个带依赖关系的DAG有向无环图描述例如steps: - id: step1 action: fetch_customer_profile inputs: {customer_id: {{intent.target.customer_id}}} outputs: [customer_data] - id: step2 action: validate_compliance inputs: {customer_data: {{step1.outputs.customer_data}}, contract_id: {{intent.target.contract_id}}} condition: {{intent.context.compliance_required}} outputs: [compliance_ok]这个DAG可被可视化引擎渲染产品经理能直接拖拽调整步骤顺序运维人员能一眼看出哪个步骤是瓶颈。执行层Execution Layer这才是真正干活的“agents”。每个agent被定义为一个最小原子能力单元例如send_email_agent、query_crm_agent、generate_pdf_agent。它们只认一种输入格式YAML定义的schema只返回一种输出格式带status、data、error字段的JSON。我们强制要求所有agent必须通过本地Mock测试才能上线确保接口契约稳定。反思层Reflection Layer这是赋予agency的关键。每个步骤执行后系统自动触发反思钩子hook用小模型分析执行结果与原始意图的匹配度。例如当send_email_agent返回“发送成功”但收件人邮箱域名是test.com明显是测试环境反思层会标记该步骤为“需人工复核”并暂停后续步骤。这个层不参与主流程但为系统提供了自我校准的能力。这四层不是堆叠关系而是管道式流转。意图层输出是规划层的输入规划层输出是执行层的输入执行层的输出又反哺反思层。每一层都可以独立灰度发布、独立监控告警、独立替换技术栈——我们曾把反思层从本地小模型换成云端大模型全程对其他层零影响。2.3 为什么拒绝“统一Agent框架”选型背后的现实权衡市面上有很多标榜“All-in-One”的智能体框架比如某些知名开源项目宣称“一个配置文件搞定所有”。我们在某模拟项目X中做过对比测试用同一套业务逻辑在统一框架和分层架构下分别实现。结果很打脸——统一框架的代码量少30%但上线后首月的故障率高4.2倍其中78%的问题集中在“配置一处全局崩塌”。根本原因在于统一框架把所有关注点意图识别、步骤编排、API调用、错误重试、日志追踪耦合在一个配置文件里。当业务方提出“这个流程里第三步如果失败要重试两次但第四步失败必须立即告警”你得在同一个YAML里嵌套三层条件判断最后那个文件长得像天书。而分层架构下重试策略属于执行层的agent配置告警规则属于反思层的hook配置互不干扰。我们最终的技术选型清单全是“乐高式”组件意图层HuggingFace Transformers 自研Prompt模板引擎支持变量注入、条件分支、多轮上下文拼接规划层Apache Airflow DAG生成器复用其成熟的状态管理、依赖解析、UI可视化能力执行层自研轻量Agent Runtime基于FastAPI每个agent是独立HTTP服务用gRPC做内部通信反思层LangChain LCEL 本地部署的Phi-3模型专用于短文本意图-结果匹配选择这些不是因为它们最新潮而是因为每一块都有成熟的运维工具链、清晰的SLA定义、和大量现成的监控指标。比如Airflow的dag_run_duration_seconds指标能直接对应到“规划耗时”而不用自己从零造轮子。这种务实选型让我们在三个月内就把系统MTTR平均修复时间从小时级降到分钟级。3. 核心细节解析让agency真正落地的五个关键控制点3.1 意图声明的Schema设计如何用12个字段框住LLM的“自由发挥”LLM的强项是生成弱点是精确。如果意图层输出的JSON结构太松散执行层就会变成灾难现场。我们花了六周时间打磨意图声明的Schema最终确定12个必填/选填字段每个字段都有明确的业务含义和校验规则。这不是拍脑袋定的而是从2000条真实用户对话中归纳出来的字段名类型是否必填说明校验规则实例intent_idstring是全局唯一标识UUIDv4格式服务端生成INT-2024-0876actionstring是标准化动作码白名单校验共47个预定义动作update_contract_expirytargetobject是操作目标实体必须包含type和id字段{type:customer,id:CUST-8821}contextobject否上下文元信息source字段必须为预设来源之一{source:email_thread_4455,urgency:high}confidencenumber是意图识别置信度0.0~1.0低于0.85触发人工审核流0.92trace_idstring否全链路追踪ID符合W3C Trace Context标准00-1234567890abcdef-abcdef1234567890-01versionstring是意图Schema版本语义化版本号用于向后兼容1.2created_atstring是生成时间戳ISO 8601格式带时区2024-06-15T14:23:1808:00expires_atstring否意图有效期默认24小时最长72小时2024-06-16T14:23:1808:00prioritynumber否执行优先级1~1010最高默认58retry_countnumber否已重试次数初始为0每次重试10metadataobject否任意扩展字段JSON Schema校验禁止嵌套过深{channel:webchat,user_tier:premium}这个Schema的关键设计哲学是用结构约束自由用字段承载语义用版本管理演进。比如action字段的白名单不是为了限制能力而是为了让执行层能提前绑定具体的agent服务——当action是update_contract_expiry时规划层就知道该调用contract-manager-agent服务而不是临时去服务发现注册中心查。注意我们严禁在metadata里塞业务核心字段。曾经有团队想把“客户手机号”放进去结果导致所有下游服务都要解析这个非标字段最后不得不全量重构。现在规则很死核心业务字段必须进target或contextmetadata只放调试、监控、AB测试用的辅助信息。3.2 规划层的DAG生成如何让LLM“画出靠谱的流程图”规划层的核心挑战是LLM擅长天马行空但DAG必须严谨无歧义。我们的解法是“三步走”先用规则引擎做硬约束再用LLM做柔性填充最后用校验器做兜底。第一步规则引擎预生成骨架我们维护一个“动作依赖知识库”记录每个action的前置条件和后置影响。例如update_contract_expiry必须在fetch_customer_profile之后执行因为需要客户等级判断是否允许修改send_email之前必须有generate_email_content步骤内容生成和发送分离便于内容审核当意图层输出action: update_contract_expiry时规则引擎会自动插入必需的前置步骤生成一个最小可行DAG骨架。第二步LLM填充动态参数在这个骨架基础上把inputs字段的占位符如{{intent.target.customer_id}}交给LLM填充。我们给LLM的Prompt非常具体你是一个DAG参数填充专家。请严格按以下规则操作 1. 只替换{{...}}中的占位符不要修改任何其他内容 2. 占位符格式为{{intent.xxx}}或{{stepN.outputs.yyy}}xxx和yyy必须是Schema中定义的字段名 3. 如果占位符指向的数据不存在返回ERROR并说明缺失字段 4. 输出必须是纯YAML不要任何解释文字这样LLM只做它最擅长的“模式匹配”不碰逻辑决策。第三步DAG校验器兜底生成的DAG会经过三道校验语法校验用PyYAML解析确保格式合法语义校验检查所有inputs引用的字段是否在上游步骤的outputs中定义循环校验用Tarjan算法检测DAG中是否存在环这是LLM最容易犯的错比如让步骤A依赖步骤B步骤B又依赖步骤A只有三道校验全通过DAG才被接受。我们在某次压力测试中发现LLM在高并发下有3.7%的概率生成带环DAG校验器直接拦截并触发降级流程——用预设的静态DAG替代保证系统可用性。3.3 执行层的Agent契约为什么每个Agent必须是“哑巴”和“聋子”执行层的agent我们有个残酷的内部称呼“哑巴聋子”。意思是它不能主动说话不产生非预期输出也不能听不懂话必须严格遵循输入Schema。每个agent的定义必须包含三样东西Input Schema一个JSON Schema文件定义它能接受的所有输入字段、类型、必填项、枚举值。例如send_email_agent的Schema强制要求to字段必须是数组、subject长度不超过100字符、body_format只能是text或html。Output Contract一个固定结构的JSON响应永远包含三个顶层字段{ status: success | failed | partial_success, data: { /* 业务数据 */ }, error: { /* 错误详情仅status!success时存在 */ } }Health Endpoint一个/healthHTTP接口返回{status:ok,timestamp:...}用于K8s探针。我们规定如果健康检查失败超过30秒服务网格自动切断流量。这个设计带来的好处是惊人的。以前当CRM系统升级APIquery_crm_agent突然开始返回新字段导致下游解析失败。现在新字段会被Schema校验器直接拒绝agent返回status: failed和明确的error.message规划层收到后可以优雅地降级到备用数据源而不是让整个流程雪崩。实操心得我们给所有agent加了一个“沙盒模式”。在测试环境agent会把所有输入输出记录到Elasticsearch并自动生成Diff报告。有一次沙盒报告发现generate_pdf_agent在处理中文时字体嵌入逻辑有细微差异导致PDF大小波动。这个bug在线上跑了两个月都没人发现因为没人监控PDF文件大小。沙盒模式成了我们最信赖的“静默守护者”。3.4 反思层的Hook机制如何让系统学会“停下来想一想”反思层不是锦上添花而是安全底线。它的核心是“Hook”——一个在每个步骤执行后、下一个步骤启动前触发的轻量级检查点。我们定义了五类标准Hook覆盖95%的异常场景Hook类型触发时机检查逻辑处理动作实例confidence_hook意图层输出后intent.confidence 0.85跳转人工审核队列置信度0.72标记为“需人工确认”consistency_hook步骤执行后比较step.output.data与intent.target的语义一致性若不一致标记status: partial_success意图要查“张三的订单”返回了“李四的订单”compliance_hook关键步骤后检查intent.context.compliance_required为true时是否有合规审批记录无记录则阻断后续步骤合同修改未获法务电子签章performance_hook步骤执行后step.duration_ms 30003秒记录慢查询触发告警CRM查询耗时5.2秒触发P2告警security_hook所有步骤前检查intent.context.source是否在白名单内非白名单来源直接拒绝来源为legacy_api_v1不在当前白名单每个Hook都是独立的、可插拔的微服务。你可以随时启用/禁用某个Hook或者用不同的模型替换它。比如consistency_hook我们初期用规则匹配后来换成小模型做语义相似度计算准确率从82%提升到94%但延迟增加了120ms。这时候我们就用performance_hook来监控一旦延迟超标自动切回规则版。最关键的实战经验是Hook的处理动作必须是幂等的。我们曾把compliance_hook的处理动作设为“发送邮件通知法务”结果因为网络抖动邮件发了三遍法务同事差点报警。现在所有Hook动作都先写入DB用唯一索引防重再异步触发通知。3.5 全链路追踪如何用Trace ID串起意图、规划、执行、反思没有追踪agency-agents就是一团乱麻。我们的追踪体系基于W3C Trace Context标准但做了关键增强Trace ID生成时机不是在用户请求进入网关时生成而是在意图层确认intent_id后生成。因为用户的一次点击可能触发多个意图比如“帮我订机票”可能同时生成“查询航班”和“查询酒店”两个意图每个意图必须有独立Trace。Span命名规范每个环节的Span Name严格按{layer}.{action}格式例如intention.classify_intentplanning.generate_dagexecution.send_email_agentreflection.consistency_hook关键属性注入每个Span都注入intent_id、step_id、agent_name、status四个属性。这样在Jaeger里搜索intent_idINT-2024-0876就能看到从意图诞生到最终结果的完整生命线。最实用的功能是“跨层跳转”。在Jaeger UI里点击一个execution.send_email_agent的Span旁边会有一个按钮“Jump to Intent”一键跳转到对应的意图声明JSON点击意图Span又能“Jump to Planning DAG”。这个功能上线后SRE团队定位问题的平均时间从22分钟缩短到3.5分钟。注意我们严禁在Span里注入敏感业务数据如客户身份证号、银行卡号。所有敏感字段都经过SHA-256哈希后存储既保留了可关联性又满足了安全审计要求。4. 实操过程详解从零搭建一个具备agency的agents系统4.1 环境准备与基础服务部署整个系统基于Kubernetes构建但为了降低入门门槛我们提供Docker Compose版用于本地开发。以下是核心服务的部署要点全部经过某公司生产环境验证1. 意图层服务intention-service基础镜像python:3.11-slim-bookworm依赖transformers4.41.2,fastapi0.111.0,prometheus-client0.17.1关键配置# config.yaml model: path: models/intent-classifier-v2 # 本地路径支持HuggingFace Hub max_length: 512 prompt: template_file: prompts/intent_prompt.j2 # Jinja2模板支持动态注入 tracing: endpoint: http://jaeger:14268/api/traces启动命令uvicorn main:app --host 0.0.0.0 --port 8000 --reload2. 规划层服务planning-service基础镜像apache/airflow:2.8.1精简版只启用Core组件关键改造替换默认DAG解析器接入自研的YAML Schema校验器添加/api/v1/generate-dagHTTP端点接收意图JSON返回DAG YAML配置要点# airflow.cfg 关键项 [core] dags_folder /opt/airflow/dags/generated load_examples False [logging] logging_level INFO3. 执行层Agent Runtimeagent-runtime基础镜像tiangolo/uvicorn-gunicorn-fastapi:python3.11设计亮点每个agent是独立进程但共享一个Runtime。Runtime提供统一的输入Schema校验基于Pydantic v2输出Contract包装自动添加status/data/errorHealth Probe/health端点Metrics暴露Prometheus格式Agent开发模板# agents/send_email_agent.py from agent_runtime import Agent, InputModel, OutputModel class SendEmailInput(InputModel): to: list[str] subject: str body: str body_format: Literal[text, html] text class SendEmailOutput(OutputModel): message_id: str sent_at: datetime class SendEmailAgent(Agent[SendEmailInput, SendEmailOutput]): async def execute(self, input: SendEmailInput) - SendEmailOutput: # 你的业务逻辑 return SendEmailOutput( message_idMSG-12345, sent_atdatetime.now() )4. 反思层Hook服务hook-service基础镜像python:3.11-slim-bookworm架构Event-driven监听Kafka Topicagent-execution-result关键配置# hooks.yaml hooks: - name: consistency_hook enabled: true model: models/semantic-similarity-v1 threshold: 0.85 - name: compliance_hook enabled: true approval_service_url: http://approval-service:8000/v1/check所有服务的Docker Compose配置我们已整理成GitHub仓库虚构名agency-agents-starter包含一键启停脚本、本地Mock数据集、和完整的CI/CD流水线配置。新手按README操作15分钟内即可跑通端到端Demo。4.2 第一个具备agency的Agent处理客户咨询的完整闭环我们以“处理客户在线咨询”为场景演示如何从零构建一个真正具备agency的agents。这个场景覆盖了所有核心环节且业务价值清晰——某公司客服系统上线后首次响应时间从4分32秒降至18秒人工介入率下降63%。Step 1定义意图Intention用户输入“我的订单#ORD-7788还没发货能查一下吗急”意图层输出简化{ intent_id: INT-2024-0877, action: track_order_status, target: {type: order, id: ORD-7788}, context: {source: webchat, urgency: high}, confidence: 0.96, trace_id: 00-1234567890abcdef-abcdef1234567890-01 }Step 2生成DAGPlanning规划层根据知识库生成DAGsteps: - id: fetch_order action: query_order_system inputs: {order_id: {{intent.target.id}}} outputs: [order_data] - id: check_warehouse action: query_warehouse_system inputs: {order_data: {{fetch_order.outputs.order_data}}} condition: {{order_data.status shipped}} outputs: [warehouse_status] - id: send_response action: send_webchat_message inputs: { to: {{intent.context.source}}, content: 您的订单{{intent.target.id}}当前状态{{fetch_order.outputs.order_data.status}}。{{#if warehouse_status}}仓库已备货预计今日发出。{{/if}} }Step 3执行AgentExecutionquery_order_systemagent调用ERP API返回{status: success, data: {order_id: ORD-7788, status: paid, created_at: 2024-06-14T10:22:15Z}}query_warehouse_systemagent因condition不满足订单状态是paid而非shipped被跳过send_webchat_messageagent发送消息“您的订单ORD-7788当前状态paid。”Step 4反思与修正Reflectionconsistency_hook运行比较intent.target.idORD-7788和fetch_order.outputs.order_data.order_idORD-7788语义一致通过。performance_hook监测到query_order_system耗时842ms低于3秒阈值不告警。Step 5用户反馈闭环用户回复“paid是什么意思我要发货”系统将此消息作为新事件再次进入意图层。这次intent.action被识别为explain_order_statusintent.target指向同一个订单context.conversation_id被继承。规划层生成新DAG调用explain_status_agent用通俗语言解释“paid”代表“已付款等待发货”并主动提供“催促发货”快捷按钮。这个闭环的价值在于系统不是被动应答而是主动管理对话状态、理解用户情绪“急”、并在上下文中持续进化。它体现的正是agency-agents区别于普通agent的核心——行为的连贯性、意图的延续性、和响应的适应性。4.3 监控与告警体系如何让运维人员睡得着觉没有监控的agency-agents就像没有仪表盘的飞机。我们构建了四层监控体系覆盖从基础设施到业务语义的全栈第一层基础设施层Infra指标CPU/Memory/Network I/O来自Prometheus Node Exporter告警agent-runtimePod内存使用率 85%持续5分钟 → P3告警Slack通知第二层服务层Service指标HTTP 5xx错误率、P95延迟、QPS来自FastAPI内置Metrics告警intention-service5xx错误率 0.5%持续2分钟 → P2告警电话通知第三层流程层Workflow指标DAG成功率、平均步骤数、各步骤平均耗时来自Airflow Metrics告警track_order_statusDAG成功率 99.5%持续10分钟 → P2告警电话通知第四层语义层Semantic指标intent.confidence平均值、consistency_hook失败率、compliance_hook阻断次数告警consistency_hook失败率 5%持续30分钟 → P1告警全员电话会议最有效的实践是“告警分级自动诊断”。当P1告警触发时系统自动执行诊断脚本抓取最近100条track_order_status意图的intent.confidence分布对比query_order_systemagent的输入输出找出高频不一致的字段生成根因报告例如“72%的不一致发生在order_data.shipping_date字段ERP系统返回空值但意图期望非空”这个报告直接推送给后端开发他们能在15分钟内定位到ERP接口变更而不是在日志海里捞针。4.4 安全与合规加固如何让agency-agents经得起审计在某金融行业客户的项目中合规部门提出了严苛要求所有意图必须可追溯、所有数据访问必须留痕、所有敏感操作必须双人复核。我们通过以下设计满足意图水印Intent Watermarking每个intent_id生成时嵌入创建者身份哈希、时间戳、和随机盐值。即使数据库被导出也无法伪造意图。数据访问门禁Data Access Gate所有agent执行前必须调用access-control-service。该服务根据intent.context中的user_role和data_sensitivity标签动态生成RBAC策略。例如query_crm_agent访问客户手机号时必须user_role为admin且intent.context.urgency为critical。操作留痕Immutable Audit Log每个步骤的执行记录含输入、输出、时间戳、Trace ID写入专用的Append-Only日志库基于RocksDB物理不可删除。审计员可随时用intent_id查询完整操作链。双人复核Dual Control对action为transfer_funds、delete_customer_data等高危动作compliance_hook强制要求intent.context.approval_ids包含至少两个不同部门的审批ID否则阻断。这些不是附加功能而是架构的DNA。当合规审计员要求“证明这个意图确实由张三发起且李四复核过”我们只需输入intent_id系统10秒内返回带数字签名的PDF报告包含所有证据链。这比任何口头承诺都管用。5. 常见问题与排查技巧实录那些只有踩过坑才知道的事5.1 “意图识别准确率忽高忽低找不到规律”——时间窗口与上下文污染现象某教育机构的智能客服系统上午准确率95%下午跌到68%日志里看不出明显错误。排查过程第一步查intent-service的/metrics发现intent_confidence_distribution直方图在下午出现大量0.4~0.6的低置信度样本。第二步抽样分析低置信度意图发现83%的输入都包含类似
