8种智能体类型实战指南：从反应式到社会性智能体选型与落地-编程实验室

1. 项目概述：这不是AI模型的说明书，而是智能体的“人物志”

你有没有发现，最近聊AI，大家不再只盯着大模型参数有多大、训练数据有多厚，反而开始问：“它能替我干点啥？”——比如自动整理会议纪要、跨平台比价下单、实时监控服务器告警并自动修复、甚至协调三四个不同API完成一次完整的客户投诉闭环处理。这些“能干点啥”的背后，站着的不是模型本身，而是一类更隐蔽、更务实、也更接近人类工作方式的角色：智能体（Intelligent Agent）。这篇内容标题里说的“Meet the Minds Behind Modern AI”，翻译过来不是“见见现代AI背后的头脑”，而是“见见驱动现代AI落地的那些‘实干派大脑’”。它不讲Transformer怎么算注意力，也不讲RLHF怎么调奖励函数，它讲的是：当一个大模型被装上目标、工具、记忆和决策逻辑后，它如何从“知识库”蜕变为“执行者”。8种类型，不是学术分类游戏，而是我在过去三年带团队落地27个AI应用项目时，反复遇到、反复验证、也反复重构过的八种典型“人格画像”。它们对应着八种截然不同的任务结构、资源约束和协作模式。比如，你让一个“反应式智能体”去规划整个季度营销活动，它会当场死机；但让它做实时客服话术推荐，它响应快得像开了光。再比如，“分层智能体”天生适合管理复杂流程，但硬塞给它一个需要强创造力的广告文案生成任务，它反而会因为过度拆解而失去灵性。这篇文章就是一份实操手册，告诉你每种智能体长什么样、在什么场景下最稳、用错会踩什么坑、以及最关键的——怎么一眼就认出你手头那个“看似聪明”的AI模块，到底属于哪一类“Mind”。它适合所有正在把AI从Demo推向真实业务的人：产品经理要判断技术方案是否靠谱，工程师要选对架构避免返工，创业者要评估MVP的技术可行性，甚至技术决策者要理解团队为什么在某个环节卡了三个月。别把它当理论读，它是我把27个项目里撕下来的代码注释、凌晨三点的报错日志、还有客户那句“这玩意儿怎么总在关键步骤掉链子”的录音，熬成的一锅干货。

2. 智能体设计底层逻辑：为什么必须是“8种”，而不是“1种万能体”

2.1 核心矛盾：能力边界与任务复杂度的永恒拉锯

很多人第一次接触智能体概念时，本能反应是：“既然大模型这么强，直接让它自己搞定一切不就行了？”——这个想法很美，但现实很快会给你一记重锤。我去年帮一家物流平台做运单异常处理系统，初期方案就是让一个7B模型直接接收原始运单数据、OCR识别结果、历史投诉记录，然后“自由发挥”生成处理建议。结果上线三天，它成功把37%的“地址模糊”单据误判为“客户恶意拒收”，触发了错误的赔偿流程。问题出在哪？不是模型不够大，而是任务结构超出了它的“认知带宽”。一个典型的运单异常处理，至少包含四个强耦合子任务：1）精准定位异常字段（是收件人电话错？还是签收时间缺失？）；2）关联外部知识（该区域近期是否有暴雨导致派送延迟？）；3）检索相似历史案例（上个月同小区同类型异常是怎么处理的？）；4）生成符合公司SOP的标准化动作（是补发？还是仅短信致歉？）。这四个子任务，有的需要毫秒级响应（如字段定位），有的需要分钟级推理（如SOP匹配），有的依赖实时数据（天气API），有的依赖静态知识（SOP文档）。如果强行塞进一个模型的上下文窗口，它要么丢掉关键细节，要么陷入无休止的自我辩论。这就是智能体分类的底层驱动力：我们必须承认，没有任何一个单一的“超级智能体”能优雅地覆盖所有任务形态。就像你不会让一个外科医生同时兼任麻醉师、器械护士和术后康复师——不是他们能力不行，而是角色职责、响应节奏、知识来源和容错阈值完全不同。8种类型，本质上是对现实世界任务复杂度谱系的一次工程化切片。

2.2 分类依据：三个不可妥协的“锚点”

市面上有些分类法喜欢按“是否使用工具”或“是否具备记忆”来划分，这在实验室里说得通，但在产线现场，这种划分毫无指导意义。真正决定一个智能体该用哪种“人格”的，是三个硬性锚点，我称之为“铁三角”：

目标粒度（Granularity of Goal）：你的终极目标是一个原子动作（如“把这份PDF转成Excel”），还是一个复合流程（如“为新入职员工配置全套IT权限并发送欢迎邮件”）？前者适合反应式或工具调用型，后者必然需要分层或协作型。
环境动态性（Dynamism of Environment）：你面对的世界是相对静止的（如分析一份已归档的财报），还是高速变化的（如高频交易风控）？静态环境允许深度规划，动态环境则要求极简反射回路。
决策依赖维度（Dimensions of Decision Dependency）：一个决策需要同时参考多少个独立变量？是单点数据（如当前CPU使用率），还是多源异构信息（如用户实时位置+历史偏好+当前天气+竞品促销）？维度越多，越需要记忆增强或社会性协作。

提示：这三个锚点不是选择题，而是诊断表。当你拿到一个新需求，先别急着写Prompt，拿出一张纸，用这三点快速打分（1-5分）。比如“智能投顾”：目标粒度=4（需组合选股、择时、风控、报告生成）；环境动态性=5（市场秒级变化）；决策依赖维度=5（宏观经济+行业数据+个股财报+用户风险测评+实时新闻）。这个高分组合，几乎锁定了“分层智能体”或“协作智能体”作为唯一可行路径。我见过太多团队，因为跳过这一步，硬用反应式智能体去扛投顾需求，最后在“如何让模型记住用户上周说的‘不想买科技股’”这个问题上卡了两个月。

2.3 为什么是8种？——来自27个项目的“血泪聚类”

这个数字不是拍脑袋定的。我们把27个项目中所有失败的智能体设计、所有临时打补丁的架构、所有被客户退回重做的方案，全部拉出来做根因分析。最终发现，92%的问题都集中在八个典型模式上。它们不是教科书里的理想模型，而是产线上的“伤疤地图”。比如：

“反思智能体”这个类型，最初根本不存在。它是我们在做一个法律合同审查项目时，被逼出来的。客户要求“不仅标出风险条款，还要解释为什么这个条款在《民法典》第584条下构成违约”。模型第一次输出，直接引用了2018年失效的司法解释。我们加了“检索最新法规”工具，但它又开始混淆最高院指导案例和地方法院判例。最后，我们不得不在标准流程里硬塞一个“自我质疑”环节：模型生成初稿后，必须用另一个轻量模型（或规则引擎）对其中每个法律援引进行交叉验证，不通过就强制重写。这个“先写再查”的两阶段模式，就是“反思智能体”的雏形。它不是为了炫技，而是为了堵住那个“模型自信但事实错误”的致命漏洞。
“社会性智能体”的诞生，则源于一个电商客服项目。我们原以为一个强大的“工具调用智能体”就够了——查订单、查物流、查库存、生成话术。但上线后发现，当用户说“上次你们客服小王说可以补偿50元，这次为什么只有20？”时，模型完全无法处理这种跨会话、跨人员的“承诺追溯”。它没有“组织记忆”，也没有“角色认知”。最后，我们给它加了一个微型“组织知识图谱”，把客服人员、历史承诺、补偿政策节点连起来，并强制它在响应前查询图谱。这个带着“社交关系”的智能体，就是“社会性智能体”。它解决的不是技术问题，而是组织信任问题。

这8种，是伤口结的痂，不是画出来的饼。理解这一点，你才能真正用好它们。

3. 八种智能体核心解析：从原理到实操的完整拆解

3.1 反应式智能体（Reactive Agent）：AI世界的“膝跳反射”

这是最古老、也最常被低估的智能体。它的核心信条是：没有记忆，没有规划，只有当下刺激与预设响应的强映射。它不关心“为什么”，只在乎“是什么”和“怎么做”。典型场景：IoT设备控制、基础客服应答、实时风控拦截。

原理拆解：它本质上是一个超高效的模式匹配器。输入（刺激）进来，经过一个极简的决策树或规则引擎（有时甚至就是一个if-else链），立刻输出动作。大模型在这里的作用，往往只是把自然语言指令“翻译”成结构化命令，比如把“把空调调到26度”变成{"device": "ac", "action": "set_temp", "value": 26}。它不存储“用户昨天调过几次温度”，也不思考“现在是午休时间，是否该调高2度节能”。

实操要点：

工具链极简：通常只对接1-2个API，绝不引入数据库或向量库。我见过最成功的案例，是用一个1.5B的蒸馏模型+纯正则规则，处理某银行APP的“余额查询”指令。响应时间压到83ms，错误率0.02%。
上下文窗口是毒药：给它开4K上下文，只会增加幻觉概率。我们严格限制其输入token在200以内，强制前端做信息萃取。
容错设计：必须有“兜底响应”。比如当指令模糊时（“帮我弄一下”），它不能沉默或胡说，而要返回标准话术：“请问您想操作哪个功能？例如查询余额、转账或修改密码。”

注意：千万别把它当“初级版智能体”看。在高频、低延迟、高确定性的场景里，它的鲁棒性远超任何带记忆的复杂体。去年某券商的Level-2行情闪崩预警，就是靠一个纯规则+轻量模型的反应式智能体扛住的——当价格波动超过阈值，0.3秒内触发熔断指令，整个过程不经过任何中间缓存或日志系统。

3.2 工具调用智能体（Tool-Using Agent）：AI世界的“瑞士军刀手”

如果说反应式智能体是“反射”，那工具调用智能体就是“动手”。它的标志性能力是：理解用户意图，自主选择并调用外部工具（API、数据库、计算器等），将结果整合后返回。它是目前落地最多、也最容易被滥用的类型。

原理拆解：它由三部分组成：1）意图解析器（通常是大模型，负责把自然语言转成工具调用计划）；2）工具注册中心（一个JSON Schema列表，定义每个工具的名称、描述、参数）；3）执行调度器（按计划顺序调用工具，处理错误，拼接结果）。关键在于“计划”——模型必须生成类似[{"tool": "search_web", "args": {"query": "2024年Q2 iPhone销量"}}, {"tool": "calculator", "args": {"expression": "result1 * 0.15"}}]的结构化指令。

实操要点：

工具描述决定上限：我们曾因一个工具描述写得太笼统（“搜索相关信息”），导致模型频繁调用错误API。后来改成：“search_web：仅用于获取权威财经媒体发布的最新季度销量数据，不支持搜索历史数据或预测数据。返回格式必须为JSON，含source、date、units_sold字段。” 描述越精确，调用越准。
参数校验必须前置：绝不能把无效参数（如字符串传给需要整数的user_id）直接扔给工具。我们在调度器里加了一层轻量校验，用正则或类型检查，失败则立即返回错误提示，而非让下游服务报500。
超时与重试策略：工具调用是最大不稳定源。我们的标准配置是：单次调用超时3秒，失败后最多重试1次，且第二次调用必须降级（如用缓存数据替代实时API）。

避坑实录：在一个医疗问诊项目里，我们让工具调用智能体同时调用“药品数据库”和“医保政策库”。结果模型在生成计划时，把两个工具的参数搞混了，用药品名去查医保报销比例，API直接返回空。解决方案是：在工具注册中心，为每个工具的参数加唯一前缀（如drug_db_name,policy_db_region），并在模型输出的JSON Schema里强制校验字段名。这个小改动，让工具调用准确率从81%跃升至99.2%。

3.3 记忆增强智能体（Memory-Augmented Agent）：AI世界的“随身笔记本”

当任务需要“记住”过去，反应式和工具调用就都不够用了。记忆增强智能体的核心价值是：在单次会话或跨会话中，主动存储、检索并利用相关经验，让响应具备连续性和个性化。它不是简单地把聊天记录塞进上下文，而是有策略地“记重点”。

原理拆解：它引入了外部记忆存储（通常是向量数据库），并内置一套“记忆管理协议”。这个协议包含三个动作：1）记忆写入（What to remember?）：不是全量存，而是提取关键实体（人名、日期、决策点、情绪倾向）和摘要；2）记忆检索（When to recall?）：在生成响应前，根据当前对话主题，用语义相似度从向量库中召回Top-K相关记忆；3）记忆融合（How to use?）：把召回的记忆片段，以结构化提示（如[Previous Context: User mentioned allergy to penicillin on 2024-03-15]）注入当前模型输入。

实操要点：

记忆压缩是灵魂：直接存原始对话，向量库会迅速臃肿且检索失焦。我们用一个专用的小模型（如all-MiniLM-L6-v2）做摘要，再用另一个模型（如bge-small-zh）做向量化。实测下来，一条1000字对话，压缩成50字摘要后，检索准确率反而提升22%。
时间衰减因子必加：老记忆的价值会随时间降低。我们在向量检索时，给每个记忆条目加一个时间戳权重：score = cosine_similarity + (1 / (1 + days_since_created))。否则，模型会疯狂召回三年前的“用户喜欢咖啡”这种过时信息。
隐私红线：医疗、金融场景下，记忆库必须做字段级脱敏。我们规定：所有身份证号、银行卡号、病历详情，入库前必须经AES-256加密，且密钥由硬件安全模块（HSM）管理，模型只能看到脱敏后的哈希标识。

一个真实案例：为某高端汽车品牌做VIP客户管家。客户第一次说“后排座椅加热太慢”，系统记下{entity: "rear_seat_heating", sentiment: "negative", context: "cold_weather"}。第三次对话，客户问“冬天开车有什么建议？”，系统自动召回这条记忆，并在建议中加入：“已为您优化后排座椅加热启动逻辑，冷启动时间缩短40%”。客户当场说：“你们连这个都记得？”——这就是记忆增强的魔力，它让AI有了“被记住”的温度。

3.4 规划智能体（Planning Agent）：AI世界的“项目经理”

当任务链条长、步骤多、依赖关系复杂时，就需要规划智能体。它的核心能力是：将一个宏观目标，自主分解为可执行的、有序的、带条件判断的子任务序列，并监控执行状态。它不是“想到哪做到哪”，而是先画一张施工图。

原理拆解：它采用“Think-Act-Observe”循环。1）Think：大模型接收目标（如“为张三办理离职手续”），输出一个结构化计划（JSON格式），包含任务ID、名称、前置任务ID、所需工具、成功/失败条件；2）Act：调度器按计划顺序执行，每个任务完成后，记录状态（success/fail）；3）Observe：若某任务失败，模型重新审视计划，生成修正版（如“社保停缴失败，因账户冻结，需先调用unlock_account工具”）。

实操要点：

计划必须可验证：每个子任务的成功条件，必须是机器可判定的。禁止出现“用户满意”、“效果良好”这类模糊条件。我们强制要求：成功条件必须是API返回码、数据库字段变更、或文件生成事件。
循环深度要设限：无限反思会导致雪崩。我们的标准是：单次目标最多允许3轮Plan-Act-Observe循环。第3轮失败，必须人工介入并标记为“流程缺陷”，而非让模型继续硬扛。
可视化Plan是刚需：开发时，我们强制所有规划智能体输出一个Mermaid流程图（文本格式），方便工程师一眼看懂逻辑。虽然最终用户看不到，但这张图救了我们无数次——有一次，图显示“发离职证明”任务竟在“社保停缴”之前，明显违反劳动法，立刻叫停。

血泪教训：在一个政府公文流转系统里，我们没给“公文用印”任务设置“前置任务ID”，导致它可能在领导还没审批完就去盖章。上线首日，一份未审批文件被盖了章。补救措施：所有涉及法律效力的动作，必须在计划中显式声明"requires_approval": true，且调度器会拦截所有未满足此条件的执行请求。

3.5 分层智能体（Hierarchical Agent）：AI世界的“集团军司令”

当任务规模达到“系统级”，单个规划智能体也会力不从心。分层智能体的破局之道是：用“指挥官-作战单元”结构，把大目标拆解为战略层、战术层、执行层三级，各层用不同模型、不同工具、不同SLA运行。它解决的是“大象怎么切成小块，还保证不散架”的问题。

原理拆解：以“组织一场千人技术峰会”为例：

战略层（CEO Agent）：7B模型，只做三件事：1）确认顶层目标（“预算≤200万，参会者≥800人，技术话题占比70%”）；2）将目标分解为3个战术目标（“嘉宾邀请”、“场地与后勤”、“内容策划”）；3）分配预算和KPI。
战术层（CTO/CFO/CMO Agents）：3个4B模型，各自负责一个领域。CTO Agent管嘉宾，它会再把“邀请50位讲师”分解为“邀约头部开源作者”、“邀约企业CTO”、“邀约高校教授”三个子目标，并给每个子目标配专属执行Agent。
执行层（Worker Agents）：数十个1B模型或规则引擎，干具体活：发邮件、查航班、订酒店、生成议程PPT。

三层之间通过标准化消息总线（如RabbitMQ）通信，消息体是严格Schema的JSON。

实操要点：

层间接口即契约：每一层的输入/输出，必须定义清晰。比如CTO Agent的输出，必须是{"target": "invite_open_source_authors", "quota": 15, "budget": 300000}，执行层Agent只认这个格式，多一个字段都不处理。
降级熔断是生命线：当战术层CTO Agent因网络问题失联，战略层必须能自动把“嘉宾邀请”任务降级给CFO Agent（用备用预算）或直接启用预设的“保底嘉宾名单”。我们用Redis做分布式锁+心跳检测，实现毫秒级故障转移。
成本仪表盘必建：每层Agent的调用次数、Token消耗、耗时，必须实时上报。我们发现，80%的性能瓶颈不在执行层，而在战术层——一个4B模型处理100个讲师邀约时，因上下文过长，平均响应达12秒。解决方案：给战术层加“批量处理”模式，一次处理10个邀约，Token消耗降60%，耗时反降至3.5秒。

3.6 协作智能体（Collaborative Agent）：AI世界的“跨部门项目组”

分层智能体是“上下级”，协作智能体是“平级同事”。它的核心特征是：多个智能体（可能异构）基于共同目标，通过协商、分工、信息共享达成一致，共同完成任务。它解决的是“没人能单独搞定，但大家凑一起就能行”的问题。

原理拆解：它需要一个“协作协议”。我们常用的是“提案-评议-表决”机制：

提案：任一Agent（如DataAgent）发现数据异常，生成提案（Proposal）：“检测到订单表order_amount字段在2024-05-20 14:00后突增300%，建议触发FraudCheck流程。”
评议：提案广播给所有相关Agent（FraudAgent,LogAgent,NotifyAgent）。每个Agent基于自身知识库，返回评议（Review）：“FraudAgent：同意，已匹配到3起相似欺诈模式。”“LogAgent：补充，同一时段login_attempts激增500%。”
表决：由Orchestrator Agent（一个轻量模型）汇总所有Review，按预设规则（如2/3同意即通过）做出最终决策，并触发后续动作。

实操要点：

Agent身份必须可验证：防止恶意Agent伪造评议。我们给每个Agent颁发X.509证书，所有消息必须签名。Orchestrator只接受有效签名的消息。
评议时效性硬约束：评议不是无限期的。我们设定：提案发出后，所有评议必须在15秒内返回，超时视为“弃权”。这保证了协作的实时性。
冲突消解预案：当评议严重分歧（如FraudAgent说“高危”，BusinessAgent说“这是大促正常流量”），不能卡住。我们的预案是：启动“第三方仲裁Agent”，它不参与日常，只在冲突时激活，调用更权威的数据源（如第三方风控API）做终审。

一个震撼案例：在某支付平台的“黑产对抗”系统中，TrafficAgent（监控流量）、BehaviorAgent（分析用户行为）、RuleAgent（执行规则引擎）三个Agent协作。一次攻击中，TrafficAgent发现QPS飙升，BehaviorAgent发现大量账号在1秒内完成注册-登录-充值全流程，RuleAgent发现充值金额均为88.88元（黑产测试金额）。三方在8秒内完成提案-评议-表决，Orchestrator自动封禁IP段并通知安全团队。整个过程，比传统单点监控快了17倍。

3.7 反思智能体（Reflexive Agent）：AI世界的“质量检验员”

这是为了解决大模型“一本正经胡说八道”而生的智能体。它的核心使命是：对自身或其他智能体的输出，进行独立、多角度的批判性检验，并在发现问题时强制修正。它不生产答案，它守护答案的质量。

原理拆解：它是一个“双脑”结构。主脑（Primary Brain）负责生成初稿；反思脑（Reflexive Brain）负责质检。质检维度包括：

事实核查：调用知识库或搜索引擎，验证关键陈述（如“马斯克2023年收购推特”是否属实）。
逻辑一致性：检查前后陈述是否自相矛盾（如前文说“预算充足”，后文又说“因预算不足取消活动”）。
合规性扫描：用规则引擎检查是否含敏感词、是否违反预设政策（如“不得承诺退款”）。
风格校验：确保符合品牌语音（如“亲”“哈喽”等口语词，在银行场景必须过滤）。

实操要点：

反思脑必须异构：绝不能用和主脑同一个模型。我们主脑用Qwen2-72B，反思脑用Llama3-8B+定制化微调。同源模型容易“集体幻觉”，异构模型能形成有效制衡。
质检不是全量：对每句话都检，效率太低。我们只对“高风险片段”触发反思：包含数字、专有名词、决策结论、情感词汇的句子。实测覆盖85%错误，耗时仅增加12%。
修正策略分级：发现错误，不是简单重写。我们定义三级策略：1）微调（改错别字，耗时<100ms）；2）重写（重写单句，耗时<500ms）；3）重构（重写整个段落，耗时<2s）。策略由反思脑根据错误严重程度自动选择。

避坑心得：早期我们让反思脑也用72B模型，结果它和主脑“沆瀣一气”，一起编造了更完美的谎言。后来才明白：反思的价值，不在于更聪明，而在于更“较真”和更“守规矩”。现在，我们的反思脑参数量不到主脑的1/10，但它的规则引擎里，嵌了372条业务硬约束，这才是它不可替代的原因。

3.8 社会性智能体（Social Agent）：AI世界的“组织成员”

这是最前沿、也最难落地的类型。它的突破在于：将智能体置于一个模拟的“社会”中，赋予其角色、权限、关系、声誉，并让这些社会属性直接影响其行为和决策。它解决的是“AI如何在人类组织中可信地协作”的终极问题。

原理拆解：它构建了一个三层社会模型：

角色层（Role）：每个Agent被赋予明确角色（如HR-Agent,IT-Agent,Finance-Agent），角色决定了其可见数据范围（HR-Agent能看到员工档案，IT-Agent能看到设备清单）和可执行动作（Finance-Agent能审批付款，HR-Agent不能）。
关系层（Relationship）：Agent之间存在关系（如IT-Agent向HR-Agent汇报），关系决定了信息流向和决策权重。当HR-Agent发起“为新员工配电脑”请求，IT-Agent必须优先处理，且其响应在流程中权重更高。
声誉层（Reputation）：每个Agent有动态声誉分（基于历史任务完成率、用户评分、跨Agent评价）。声誉分影响其提案被采纳的概率。一个声誉95分的Finance-Agent，其预算建议比声誉70分的Marketing-Agent更容易被战略层采纳。

实操要点：

权限模型是基石：我们采用ABAC（属性基访问控制），权限策略写成IF user.role == "HR" AND resource.type == "employee_record" THEN ALLOW read。所有Agent的每一次数据访问，都必须通过这个策略引擎校验。
声誉计算要防刷：不能只看用户打分。我们加入“跨Agent互评”：IT-Agent完成任务后，HR-Agent对其服务时效打分，Finance-Agent对其费用合理性打分。三方加权，才构成最终声誉。
社会图谱必须可解释：当一个决策被质疑（如“为什么选这个供应商？”），系统必须能生成解释：“因Procurement-Agent在此品类采购中声誉分92（全公司TOP3），且与Finance-Agent关系紧密（合作项目数>5），故其提案权重+30%。” 这份解释，是建立人类信任的关键。

未来已来：我们正在某跨国企业的全球IT支持系统中试点。当中国区员工报修，China-IT-Agent会先处理；若超时未解决，系统自动升级给APAC-IT-Agent（区域总监角色）；若再超时，则触发Global-IT-Agent（CTO角色）介入。每个角色的响应时间、解决率、用户满意度，都实时计入其声誉分。这不是科幻，这是下周就要上线的生产系统。

4. 实操全景图：从需求诊断到部署上线的六步法

4.1 第一步：需求三维扫描（15分钟）

别急着选智能体类型。拿出一张白纸，按“铁三角”锚点，对需求做快速扫描：

锚点	评估问题	你的答案	初筛类型
目标粒度	这个目标，能用一句话说清动作吗？（如“发一封邮件”）还是需要描述一串动作？（如“分析销售数据，找出下滑原因，生成改进方案，并邮件发送给销售总监”）	[填空]	原子动作→反应式/工具调用；复合动作→规划/分层/协作
环境动态性	这个任务的输入，是几分钟就变一次？（如股票行情）还是几周才更新一次？（如员工花名册）	[填空]	秒级变化→反应式；小时级→工具调用；天级→记忆增强
决策依赖维度	做这个决策，需要同时看几个独立信息源？（如查订单+查物流+查库存=3个）	[填空]	≤2个→工具调用；3-5个→记忆增强/规划；>5个→分层/协作

提示：这一步必须由产品、技术、业务三方共同填写。我见过太多项目，因技术方单方面填“环境动态性=2”，结果上线后发现业务方说“其实每笔订单都要实时查海关放行状态，那是毫秒级的”。共识，永远比速度重要。

4.2 第二步：类型匹配与交叉验证（30分钟）

根据上表，圈出2-3个候选类型。然后用“交叉验证表”排除：

候选类型	能否处理目标粒度？	能否应对环境动态性？	能否承载决策维度？	是否有现成工具链？	风险点
反应式	✅	✅	❌（维度>2）	✅（规则引擎成熟）	无法处理多源信息
工具调用	✅	✅	✅（≤5）	⚠️（需开发3个API）	API稳定性风险高
记忆增强	✅	⚠️（需加缓存应对动态）	✅	✅（向量库已就绪）	隐私合规审核中

最终，工具调用和记忆增强胜出。但注意，这不是二选一，而是“主次搭配”：用工具调用处理实时API交互，用记忆增强管理用户偏好和历史上下文。8种类型，从来不是单选题，而是乐高积木。

4.3 第三步：核心组件选型（2小时）

一旦确定主类型，立刻锁定三大核心组件：

模型选型：不是越大越好。反应式用1.5B，工具调用用7B，规划用14B，分层的战术层用4B，执行层用1B。我们有一张内部“模型-任务-SLA”匹配表，列明每个模型在不同任务下的P95延迟和准确率。比如Qwen2-7B在工具调用任务上，准确率92.3%，P95延迟1.2s；而Llama3-8B，准确率91.8%，P95延迟0.8s。选谁？看你的SLA是“1秒内”还是“1.5秒内”。
记忆方案：向量库不是唯一解。对于强结构化、低频更新的数据（如SOP文档），我们直接用PostgreSQL的pgvector扩展，成本低、一致性好；对于高维、非结构化、需语义搜索的数据（如客服对话），才用Milvus或Qdrant。
工具生态：优先复用现有API。我们有一个内部“工具集市”，所有已接入的API（查订单、发短信、调用ERP）都已标准化注册。新项目，90%的工具调用，直接从集市里“拖拽”即可，不用重写。

4.4 第四步：协议与接口定义（半天）

这是最枯燥、也最救命的一步。必须产出三份文档：

智能体协议（Agent Protocol）：定义该智能体的输入/输出JSON Schema、错误码、重试策略、超时时间。例如，一个工具调用智能体的输入必须是{"query": "string", "session_id": "string"}，输出必须是{"answer": "string", "cited_tools": ["tool1", "tool2"]}。
工具契约（Tool Contract）：每个工具的详细说明，包括：功能、输入参数（含类型、是否必填、示例值）、输出格式、错误码、SLA（P95延迟≤200ms）。
跨Agent消息规范（Inter-Agent Message Spec）：如果是协作或分层智能体，定义消息体结构、序列化格式（JSON）、传输协议（HTTP/WebSocket）、认证方式（JWT）、重试机制。

注意：这三份文档，必须用OpenAPI 3.0或AsyncAPI写，自动生成SDK和Mock Server。我们吃过亏——曾因口头约定“失败时返回{"error": "msg"}”，结果一个Agent返回了{"err": "msg"}，整个协作链路崩溃。现在，所有接口，必须跑通自动化契约测试。