Hermes Agent：可复盘、可成长的智能体架构设计-洪萨配资

1. 项目概述：一个真正会“复盘”的Agent，不是加个日志模块就叫成长

最近在几个技术社区里反复看到“Hermes Agent”这个词，尤其高频出现在AI工程实践、智能体开发和复杂任务自动化讨论中。它不像那些只强调“调用多个工具”或“堆砌大模型API”的Demo型Agent，而是被不少一线团队称为“第一个让我觉得Agent真能自己变强的系统”。核心关键词就两个——复盘和可成长。注意，这里说的“复盘”不是指人手动翻看历史记录，而是系统级的、自动触发的、带因果推理的决策回溯；而“可成长”也不是简单地微调一下模型权重，而是指在不重训基座模型的前提下，通过结构化记忆、策略迁移和失败归因，让Agent在同类任务上的成功率逐次提升。我去年参与过一个金融风控场景的Agent落地项目，初期版本上线后，对“异常交易模式识别”这类任务的准确率稳定在72%左右，但每次误判后，系统只会记录错误样本，人工分析周期长达3天。换成Hermes架构后，同样的误判触发自动复盘流程：它会拉取当时完整的上下文链（用户原始请求、工具调用序列、中间推理状态、最终输出与真实标签的偏差），用轻量级校验器定位是哪一环出错——是意图解析偏移？还是工具参数构造错误？抑或是多步推理中的逻辑断点？定位后，它不改模型，而是生成一条新的“策略规则”，比如“当检测到‘跨时区高频小额转账’且收款方为新注册商户时，强制插入反洗钱规则引擎二次校验”，这条规则被编译进运行时策略库，下次同类请求直接命中。实测6周内，该任务准确率从72%爬升到89.3%，且人工干预频次下降76%。这背后不是玄学，而是整套架构对“经验沉淀-规则提炼-策略注入-效果验证”闭环的工程化封装。如果你正在被“Agent上线后永远卡在80分瓶颈”困扰，或者厌倦了每次优化都要重新标注、重训、重部署的沉重流程，那Hermes的思路值得你沉下心来拆解。它解决的不是“能不能跑起来”的问题，而是“能不能越跑越聪明”的根本命题。

2. Hermes Agent 架构设计全景：四层解耦，把“成长能力”变成可插拔模块

Hermes不是单体黑盒，它的核心价值恰恰藏在清晰的分层解耦里。整个架构严格划分为四层：感知层（Perception Layer）、决策层（Reasoning Layer）、执行层（Execution Layer）、复盘层（Retrospection Layer）。这四层之间通过定义明确的契约接口通信，任何一层都可以独立替换或升级，而不会牵动全局。这种设计直接服务于“可成长”目标——成长能力不是写死在模型里的天赋，而是由复盘层驱动、在决策层落地、经执行层验证的标准化流程。下面我结合实际部署案例，逐层拆解其设计逻辑与关键取舍。

2.1 感知层：不止于“听懂”，更在于“听全”和“听准”

感知层是Agent的感官系统，负责将原始输入（文本、语音转写、API请求体等）转化为结构化、带置信度的内部表征。Hermes在此处做了两个关键突破：多模态上下文锚定和意图漂移检测。传统Agent常把用户一句话当作独立事件处理，而Hermes会主动关联当前会话的完整历史、用户画像快照（如权限等级、历史偏好标签）、甚至外部实时信号（如服务健康度、市场波动指数）。例如，在客服场景中，用户说“帮我查昨天那笔退款”，感知层不会只提取“查退款”这个动作，而是自动绑定“昨天”这个时间锚点到会话时间戳，并检索用户最近3次会话中所有含“退款”关键词的交互片段，形成上下文图谱。更重要的是，它内置了一个轻量级LSTM意图漂移检测器，持续监控用户表述的语义向量变化。当检测到连续两轮对话中，用户提问的嵌入向量夹角超过预设阈值（我们线上设为0.42），系统会主动触发“意图澄清”子流程，而不是强行推理。这个阈值不是拍脑袋定的——我们用生产环境10万条真实会话做聚类分析，发现0.42是区分“自然话题延伸”与“用户表达混乱/需求变更”的最优分割点。> 提示：很多团队在感知层过度依赖大模型做端到端理解，结果导致延迟高、成本炸、不可控。Hermes坚持“小模型做确定性感知，大模型做不确定性推理”的原则，感知层全部用<50M参数的蒸馏模型，推理耗时稳定在80ms内，为后续复盘留出充足时间窗口。

2.2 决策层：动态策略路由，让“思考路径”本身成为可优化资产

决策层是Agent的大脑，但Hermes把它设计成了一个“策略路由器”。它不固化一套推理链，而是维护一个策略知识库（Strategy Knowledge Base, SKB），里面存储着三类资产：基础策略模板（如“标准故障排查五步法”）、场景化策略包（如“电商大促期间库存预警专项策略”）、自生长策略规则（即复盘层产出的增量规则）。当感知层输出结构化意图后，决策层首先进行策略匹配度计算：用Jaccard相似度比对当前上下文特征向量与SKB中每条策略的适用条件向量，筛选出Top-3候选策略。接着启动策略融合引擎——它不是简单选一个，而是将Top-3策略的执行步骤打散、按依赖关系重组，生成一条混合路径。比如，基础策略要求“先查日志再调API”，而自生长规则要求“遇到特定错误码必须跳过日志直连数据库”，融合引擎会自动将后者插入前者流程的对应断点。这个过程的关键在于策略的可组合性设计：每条策略都必须声明自己的输入约束、输出契约、副作用范围和回滚预案。我们曾踩过坑：早期策略规则没定义副作用范围，导致一条“强制刷新缓存”的规则被错误注入到支付流程中，引发数据不一致。后来强制要求所有策略提交前必须通过副作用沙箱测试，才彻底解决。> 注意：策略知识库不是静态文档库，它有版本控制（Git式分支）、灰度发布（按用户ID哈希分流）和A/B效果追踪（每条策略执行后自动上报成功率、耗时、错误类型）。这才是“可成长”的基础设施。

2.3 执行层：工具即服务，失败即数据

执行层负责把决策层输出的混合路径，翻译成具体工具调用。Hermes对此的革新在于工具抽象协议（Tool Abstraction Protocol, TAP）。它不关心工具是Python函数、REST API还是数据库SQL，只要工具提供者按TAP规范实现三个接口：describe()（返回工具能力描述、参数Schema、调用示例）、validate()（预检参数合法性）、execute()（执行主体）。这个设计让工具接入成本趋近于零——我们曾用2小时就把一个遗留的COBOL批处理程序包装成TAP工具。更重要的是，执行层内置失败归因分析器（Failure Attribution Analyzer, FAA）。当某次工具调用失败，FAA会自动抓取：调用前的输入参数快照、工具返回的原始错误码与消息、工具自身的健康指标（如响应延迟、错误率）、以及同一时段其他工具的调用表现。然后基于预置的归因树（Root Cause Tree）进行匹配。比如，错误码DB_CONN_TIMEOUT会先匹配“网络层问题”，再根据同网段其他工具是否也超时，判断是全局网络抖动还是单点DB故障。归因结果直接喂给复盘层，成为策略优化的黄金数据源。我们线上统计，83%的执行失败能在10秒内完成精准归因，而传统方案依赖人工查日志平均耗时17分钟。

2.4 复盘层：真正的“成长引擎”，闭环设计决定上限

复盘层是Hermes的灵魂，它不是一个事后分析模块，而是与前三层深度耦合的实时反馈中枢。其核心是三阶触发机制：

显式触发：用户主动点击“复盘本次操作”按钮，或管理员配置的定期巡检任务；
隐式触发：当执行层FAA检测到高危错误（如支付失败、数据删除），或决策层策略融合引擎连续3次选择同一策略包，系统自动唤醒复盘；
被动触发：外部系统推送信号，如风控平台标记某次操作为“疑似欺诈”，复盘层立即拉取全链路数据。

触发后，复盘层启动四步原子流程：

链路重建（Trace Reconstruction）：从分布式追踪系统（如Jaeger）拉取本次任务的完整Span链，还原每个环节的输入、输出、耗时、状态；
偏差定位（Deviation Localization）：用Diff算法比对预期输出（基于策略契约）与实际输出，定位偏差发生在哪个决策节点或执行步骤；
根因推演（Root Cause Inference）：调用轻量级因果推理模型（基于Do-Calculus构建），结合上下文变量（如用户等级、时段、系统负载），推断最可能的根本原因；
策略生成（Strategy Generation）：将根因转化为可执行策略规则，经语法检查、副作用沙箱验证、影响面评估（Impact Scope Analysis）后，注入SKB。

这个闭环的威力在于策略的“可验证性”。每条新策略都自带验证用例——复盘层会用历史失败样本回放，确认新策略能覆盖该场景；同时用随机采样1000个成功样本做负向验证，确保不破坏原有能力。我们线上策略的首次通过率（无需人工修改即可上线）达68%，远高于行业平均的22%。

3. 核心机制深度解析：复盘如何驱动“可成长”，而非制造噪音

很多人以为“加个复盘功能”就是让Agent成长，实则不然。Hermes的复盘机制之所以有效，在于它用一套精密的过滤、提炼、验证体系，把海量运行数据转化为高质量策略资产。下面我以一个真实金融风控场景为例，手把手拆解一次典型复盘的完整链条，展示每个环节的设计精妙之处。

3.1 场景还原：一次“看似合理”的误判

某日早10:15，一位VIP客户发起一笔50万元的跨境汇款。Hermes Agent按标准流程执行：

感知层识别出“跨境汇款”意图，关联客户VIP标签与历史无异常记录；
决策层匹配“VIP客户快速通道”策略包，跳过常规KYC复核；
执行层调用SWIFT网关发送指令；
3秒后，执行层收到银行返回错误码SWIFT_REJECT_403，含义为“受益人账户受限”。

此时，传统Agent可能只记录：“客户XXX汇款失败，错误码403”。而Hermes复盘层被隐式触发，开始工作。

3.2 链路重建：还原每一个“为什么”

复盘层首先从Jaeger拉取本次调用的12个Span：

perception_intent_parse：输入文本向量、意图置信度0.92、VIP标签置信度0.88；
reasoning_strategy_match：匹配策略包vip_fast_track_v3.2，匹配度0.95；
execution_swift_call：输入参数含受益人IBAN、金额、附言；
execution_swift_response：返回HTTP 403，Body含{"reason":"Beneficiary account restricted by local regulator"}。

关键发现：感知层对“VIP标签”的置信度（0.88）虽高，但低于决策层策略包要求的阈值（0.90）。这意味着策略匹配存在“勉强通过”风险，但系统未告警。这是第一个偏差点。

3.3 偏差定位：找到“断裂”的那一环

复盘层比对策略契约与实际结果：

策略契约要求：“VIP客户汇款应100%成功，或返回可操作的明确拒绝原因”；
实际结果：“返回模糊的监管限制原因，无后续操作指引”。

偏差定位在执行层的错误处理契约上。原设计认为SWIFT网关返回的403错误足够明确，但实际业务中，“监管限制”可能指向数十种细分场景（如受益国制裁名单、账户冻结、反洗钱临时审查），需要不同应对策略。而当前执行层只做了通用错误映射，丢失了关键细分信息。

3.4 根因推演：穿透表象找本质

复盘层启动因果推理模型，输入变量包括：

客户属性：VIP等级、国籍、常驻地；
受益人属性：IBAN所属国家、银行代码；
系统状态：SWIFT网关过去1小时错误率（0.3%）、本地风控规则更新时间（2小时前）；
历史数据：过去7天同类错误中，87%发生在受益人为东南亚某国银行时。

模型输出根因概率分布：

“受益人银行所在国近期新增制裁名单”（概率62%）；
“本地风控规则未同步最新SWIFT错误码映射表”（概率28%）；
“客户VIP标签未包含跨境监管豁免权限”（概率10%）。

最高概率项直指外部数据同步机制缺陷，而非Agent自身逻辑错误。

3.5 策略生成：从教训到武器

基于根因，复盘层生成策略规则：

{ "id": "STRAT_SWIFT_403_ENHANCE", "trigger": { "tool": "swift_gateway", "error_code": "SWIFT_REJECT_403", "context": "beneficiary_country IN ['TH', 'VN', 'MY']" }, "action": { "pre_check": "call_regulatory_list_api(country=beneficiary_country, last_updated_hours<1)", "fallback": "inject_manual_review_step(reason='Regulatory list sync lag')" }, "impact_scope": { "affect_users": "VIP+ customers with beneficiary in TH/VN/MY", "risk_level": "MEDIUM" } }

这条规则的核心创新在于前置校验（pre_check）：在执行SWIFT调用前，先调用监管名单API确认数据新鲜度。若发现本地缓存过期，则跳过自动执行，进入人工复核。规则生成后，自动触发：

语法检查：确认JSON格式、字段合法性；
沙箱验证：用模拟数据测试regulatory_list_api调用是否超时、返回是否符合预期；
影响面评估：确认仅影响泰国/越南/马来西亚三国受益人，且限于VIP+客户，风险可控；
A/B测试：对5%的匹配流量灰度启用，监控成功率与人工介入率。

实测显示，该策略上线后，同类错误的人工介入率下降91%，平均处理时长从47分钟缩短至3.2分钟。这就是“可成长”的真实模样——不是模型变大，而是系统变得更懂业务、更懂边界、更懂何时该停下。

4. 实操部署指南：从零搭建可复盘Agent的最小可行架构

理论再扎实，落不了地都是空谈。我以一个电商售后场景的Agent为例，给出Hermes架构的最小可行部署方案（MVP），所有组件均选用开源、易运维、低学习成本的技术栈，确保你在2天内就能跑通完整复盘闭环。重点不是堆砌高端技术，而是抓住架构主干。

4.1 环境准备：轻量级但不失健壮

我们放弃K8s集群起步，用Docker Compose搞定一切。核心服务共5个容器：

hermes-core：主Agent服务，Python 3.11 + FastAPI，承载感知、决策、执行三层；
retro-engine：复盘引擎，Rust编写（高性能要求），暴露gRPC接口；
strategy-db：策略知识库，PostgreSQL 15，专设strategies表（含id, content, version, impact_scope, created_at）；
trace-db：分布式追踪存储，Jaeger All-in-One（内存模式，够MVP用）；
mock-tools：模拟工具集，包含refund_api、inventory_check、log_search三个HTTP服务，用于快速验证。

提示：别一上来就搞Elasticsearch存日志。Jaeger内存版启动只需docker run -d -p 16686:16686 jaegertracing/all-in-one:1.45，5秒完事。等你的Agent每天处理10万次请求时，再考虑迁移到Cassandra后端。

4.2 核心配置：让复盘“活”起来的3个关键开关

Hermes的复盘能力不是默认开启的，需要在hermes-core的config.yaml中精准配置三个开关：

复盘触发阈值（retrospection.triggers）：

triggers: explicit: true # 是否响应用户手动复盘请求 implicit: error_codes: ["SWIFT_REJECT_403", "REFUND_FAILED"] # 显式错误码列表 strategy_stuck: 3 # 同一策略连续命中次数阈值 latency_spike: 2000 # 毫秒，单次执行超时阈值 passive: false # MVP阶段先关掉被动触发，避免外部依赖

这个配置决定了系统“多敏感”。我们建议MVP从error_codes入手，聚焦高频失败点。

策略注入策略（strategy_injection）：

injection: mode: "gray" # 灰度模式，非"direct"（直发）或"review"（需人工审核） gray_ratio: 0.05 # 5%流量灰度 validation: positive_cases: 100 # 用100个历史成功样本做负向验证 negative_cases: 50 # 用50个历史失败样本做正向验证

灰度是生命线。没有灰度的策略注入，等于给生产环境埋雷。

复盘深度（retrospection.depth）：

depth: trace_rebuild: true # 必须开，否则复盘无数据 deviation_localization: true # 必须开，否则找不到问题点 root_cause_inference: false # MVP先关掉，用规则引擎替代（见4.3节） strategy_generation: true # 必须开，否则不生成策略

因果推理模型需要大量标注数据训练，MVP阶段用硬编码规则树更稳。

4.3 策略知识库初始化：填好第一块砖

strategy-db初始化脚本init_strategies.sql至关重要，它定义了Agent的“常识底线”。MVP只需3条基础策略：

标准退款流程（STRAT_REFUND_STANDARD）：

INSERT INTO strategies (id, content, version, impact_scope) VALUES ( 'STRAT_REFUND_STANDARD', '{ "name": "Standard Refund Flow", "trigger": {"intent": "refund_request"}, "steps": [ {"tool": "log_search", "params": {"order_id": "{order_id}"}}, {"tool": "refund_api", "params": {"order_id": "{order_id}", "amount": "{amount}"}} ], "output_contract": {"status": "success|failed", "reason": "string"} }', '1.0', '{"affect_users": "all", "risk_level": "LOW"}' );

VIP客户加速通道（STRAT_VIP_FAST_TRACK）：

INSERT INTO strategies (id, content, version, impact_scope) VALUES ( 'STRAT_VIP_FAST_TRACK', '{ "name": "VIP Fast Track", "trigger": {"intent": "refund_request", "user_tier": "VIP"}, "steps": [ {"tool": "refund_api", "params": {"order_id": "{order_id}", "amount": "{amount}"}} ], "output_contract": {"status": "success|failed", "reason": "string"} }', '1.0', '{"affect_users": "VIP only", "risk_level": "MEDIUM"}' );

失败兜底策略（STRAT_FALLBACK_MANUAL）：

INSERT INTO strategies (id, content, version, impact_scope) VALUES ( 'STRAT_FALLBACK_MANUAL', '{ "name": "Fallback to Manual Review", "trigger": {"error_code": "REFUND_FAILED"}, "steps": [{"tool": "notify_human_agent", "params": {"case_id": "{case_id}"}}], "output_contract": {"status": "pending_human_review"} }', '1.0', '{"affect_users": "all", "risk_level": "CRITICAL"}' );

这三条策略构成了Agent的“安全网”。没有它们，复盘生成的新策略就无处安放。

4.4 一次完整复盘实操：从失败到策略上线

现在，我们模拟一次真实复盘。启动所有容器后，用curl触发一次失败退款：

curl -X POST http://localhost:8000/agent/execute \ -H "Content-Type: application/json" \ -d '{ "intent": "refund_request", "params": {"order_id": "ORD-7890", "amount": "299.00", "user_tier": "VIP"}, "trace_id": "trace-abc123" }'

mock-tools/refund_api故意返回{"status":"failed","error_code":"REFUND_FAILED"}。

执行层捕获失败：hermes-core记录错误，向Jaeger上报Span，触发复盘层；
复盘层启动：retro-engine拉取trace-abc123全链路，定位到refund_api调用失败；
策略生成：因root_cause_inference关闭，引擎直接匹配预置规则树，发现REFUND_FAILED应走STRAT_FALLBACK_MANUAL，但当前VIP客户被STRAT_VIP_FAST_TRACK策略绕过了兜底。于是生成新策略：
```
{ "id": "STRAT_VIP_REFUND_SAFETY", "trigger": {"intent": "refund_request", "user_tier": "VIP", "error_code": "REFUND_FAILED"}, "action": {"fallback": "STRAT_FALLBACK_MANUAL"} }
```
灰度注入：策略写入strategy-db，hermes-core监听到新策略，按5%比例对后续VIP退款请求启用；
效果验证：10分钟后，查看strategy-db的strategy_metrics表，确认新策略的success_rate为100%（因全部转人工，不再失败）。

整个过程，从失败发生到策略生效，耗时<90秒。你不需要碰一行大模型代码，成长已经发生。

5. 常见问题与避坑指南：那些只有踩过才知道的“深坑”

部署Hermes不是一键安装那么简单。我在3个不同行业的落地项目中，总结出最痛、最隐蔽、文档里绝不会写的5个深坑。避开它们，能帮你省下至少200小时的调试时间。

5.1 坑一：复盘数据“太全”反而失效——链路重建的精度陷阱

现象：复盘层拉取的Trace数据量爆炸，单次复盘耗时从2秒飙升到47秒，CPU打满，最终OOM崩溃。
根因：Jaeger默认采集所有Span，包括健康检查、心跳、内部监控等无关链路。Hermes的链路重建引擎试图解析所有1000+个Span，而其中95%与业务无关。
解决方案：在Jaeger客户端强制打标过滤。在hermes-core的OpenTelemetry配置中，添加：

# 只采集业务关键Span tracer.add_span_processor( SimpleSpanProcessor( BatchSpanProcessor( JaegerExporter( agent_host_name="jaeger", agent_port=6831, # 关键：只导出带特定tag的Span max_tag_length=1024, ) ) ) ) # 在业务Span创建时，强制添加业务标签 with tracer.start_as_current_span("refund_api_call", attributes={"span_type": "business"}) as span: # ... 执行逻辑

同时，在Jaeger UI的Search界面，设置Filter为span_type = business。实测后，单次复盘Span数量从1200+降至平均23个，耗时稳定在1.8秒内。> 注意：别信“全量采集，后期过滤”的说法。复盘是实时过程，数据量是硬门槛。

5.2 坑二：策略冲突——当两条“正确”规则打架

现象：上线两条策略后，Agent在某个场景下行为诡异：有时走A流程，有时走B流程，无法预测。
根因：策略匹配度计算使用Jaccard相似度，但当两条策略的适用条件向量高度重叠时（如user_tier=VIP和user_tier=VIP_PLUS），相似度分数接近，决策层随机选择。
解决方案：引入策略优先级（Priority）和互斥组（Mutex Group）。在策略JSON中增加：

"priority": 10, // 数值越大，优先级越高 "mutex_group": "refund_safety" // 同组策略互斥，只选最高优先级

并在决策层的策略融合引擎中，增加互斥校验逻辑：先按mutex_group分组，每组内取priority最高者，再对各组胜出者做Jaccard匹配。我们线上策略库中，refund_safety组有7条策略，优先级从5到25，确保VIP客户退款失败时，永远先触发安全兜底，而非尝试重试。

5.3 坑三：复盘“假阳性”——把偶发抖动当根本原因

现象：复盘层频繁生成“优化策略”，但上线后效果为零，甚至降低成功率。
根因：FAA（失败归因分析器）将网络抖动、瞬时超时等偶发问题，误判为系统性缺陷，生成无效策略。例如，将一次DB_CONN_TIMEOUT归因为“连接池配置不足”，而实际是机房电力波动。
解决方案：实施“三现主义”归因验证——必须满足三个条件才触发根因推演：

现场：同一工具在5分钟内连续失败≥3次；
现物：失败时，该工具的上游依赖（如DB、Redis）也出现异常指标（错误率>5%或P99延迟>2s）；
现实：失败时段，外部监控系统（如Zabbix）有对应告警。
我们在FAA中硬编码了这三条规则，过滤掉82%的偶发抖动，使复盘生成的有效策略率从31%提升至79%。

5.4 坑四：策略“膨胀癌”——知识库越积越多，决策越来越慢

现象：运行3个月后，策略库从23条涨到387条，决策层匹配耗时从120ms涨到2.3秒，用户明显感知卡顿。
根因：策略知识库缺乏生命周期管理，旧策略从未下线，而新策略又不断加入，形成“策略雪球”。
解决方案：建立策略“冷热分离”与自动淘汰机制：

冷热分离：数据库表增加last_used_at和usage_count字段；

自动淘汰：每日凌晨执行SQL：

DELETE FROM strategies WHERE usage_count < 5 AND last_used_at < NOW() - INTERVAL '30 days' AND risk_level != 'CRITICAL';

热度提醒：当某策略连续7天usage_count=0，自动邮件通知负责人确认是否废弃。
我们上线此机制后，策略库规模稳定在120±15条，决策耗时回归150ms以内。

5.5 坑五：复盘“黑箱”——工程师看不懂Agent为什么这么干

现象：当业务方质疑某次复盘结论时，工程师无法向其解释“为什么推断是监管名单问题”，只能甩出一串模型输出。
根因：因果推理模型（即使轻量级）仍是黑箱，缺乏可解释性输出。
解决方案：强制策略生成带“归因证据链”。每条新策略JSON中，必须包含evidence_trace字段：

"evidence_trace": [ {"step": "FAA_detected_error", "data": "SWIFT_REJECT_403"}, {"step": "context_enriched", "data": "beneficiary_country=TH"}, {"step": "external_data_checked", "data": "regulatory_list_last_updated=2h_ago"}, {"step": "historical_pattern_matched", "data": "87%_of_403_errors_from_TH_in_last_7d"} ]

前端复盘报告页面，直接渲染此证据链为时间轴，业务方一眼看懂推导逻辑。这招让我们与风控部门的协作效率提升了3倍，他们甚至开始主动提供监管名单更新频率等外部数据。

这些坑，每一个都曾让我在凌晨三点对着监控面板抓狂。但填平它们的过程，恰恰是理解Hermes“可成长”本质的最好课堂——成长不是魔法，而是对数据、对边界、对人性的敬畏与精密设计。