1. 项目概述为什么我们需要自己的“滑翔马”最近AI Agent智能体这个概念火得不行感觉是个技术大会不提Agent就落伍了。铺天盖地的框架、平台和“一站式解决方案”看得人眼花缭乱从AutoGPT到LangChain再到各种云服务商推出的Agent服务似乎谁都能帮你快速“组装”一个智能体。但作为一个在一线折腾了十多年的老码农我总感觉哪里不对劲。这些框架确实降低了门槛但它们往往也预设了路径封装了“黑箱”你按照它的模板填参数、写提示词最后出来的Agent可能能跑但你很难说清楚它内部每一步决策的逻辑更别提针对自己独特的业务场景进行深度定制和性能调优了。这就好比给你一辆组装好的赛车你能开但你想换个更适合山路的悬挂或者调整一下引擎的进排气却发现无从下手。所以当团队提出要做一个代号为“Gliding Horse”滑翔马的AI Agent项目时我的第一反应是兴奋而不是畏惧。我们不想再当框架的“调参侠”而是想从第一性原理出发理解Agent运作的每一个环节并打造一套属于我们自己的、高度可控的“缰绳”与“鞍具”——这就是我们内部称之为Agent Harness的核心理念。Gliding Horse不是另一个通用Agent框架它是我们为解决特定领域复杂任务而设计的专用智能体而Agent Harness则是确保这匹“马”能听话、高效、稳健奔跑的基础设施层。今天我就来拆解一下Gliding Horse的设计细节尤其是Harness层的构建思路希望能给那些不想盲目跟风希望真正掌握Agent开发主动权的朋友们一些启发。2. 核心理念拆解Harness不是Agent而是它的“操作系统”在开始聊技术细节前必须厘清一个关键概念Agent Harness 和 AI Agent 核心Core Agent是两回事。这是很多初学者甚至一些项目容易混淆的地方。AI Agent核心是什么你可以把它想象成这匹“马”的大脑和本能。它基于大语言模型LLM具备理解、规划、推理和执行的能力。它的核心职责是接收任务拆解任务调用工具Tools/Skills并根据反馈调整策略最终完成任务。这是一个“智能”的部分负责产生意图和决策。Agent Harness又是什么它不是马的大脑而是缰绳、鞍具、蹄铁、导航系统和健康监测仪的总和。它是一套包裹在AI Agent核心推理逻辑之外的基础设施层。Harness不负责代替Agent做决策那是LLM的活它的核心使命是管理、约束、保障和优化Agent的行为。具体来说Harness要解决以下问题生命周期管理Agent的启动、暂停、恢复、销毁。你不能让一匹马乱跑需要能随时叫停它。状态与上下文管理在复杂的多轮对话和任务链中准确维护对话历史、中间结果、工具调用状态。这好比骑手的记忆和马匹的体力记录。工具Skill的注册、发现与安全调用Harness需要提供一个安全沙箱让Agent能可靠地调用外部工具如搜索API、数据库操作、代码执行同时防止危险操作。这是给马匹套上安全的“衔铁”和“护腿”。流程与工作流控制引入如PDCAPlan-Do-Check-Act这样的管理循环或者SMARTSpecific, Measurable, Achievable, Relevant, Time-bound原则来框定任务目标。Harness负责驱动这个循环确保Agent的执行不偏离轨道。例如在“Plan”阶段Harness可以要求Agent输出可验证的计划步骤在“Check”阶段Harness可以自动评估结果并决定是重试、调整还是报错。可观测性Observability与调试实时记录Agent的思考过程Chain-of-Thought、工具调用详情、耗时、token消耗等并提供可视化界面。当Agent行为异常时你能像汽车技师读OBD数据一样快速定位问题。这是给马匹安装的“运动传感器”和“黑匣子”。资源与成本控制监控和管理API调用次数、token消耗避免预算失控。持久化与持久记忆将重要的会话状态、学习到的经验保存下来供下次任务使用。所以Harness更像是一个轻量级的、为Agent定制的“操作系统”或“运行时环境”。一个强大的Harness能让一个中等能力的Agent核心比如一个合适的开源模型发挥出远超其本身水平的稳定表现。而我们开发Gliding Horse很大程度上是在精心打造这个Harness层。注意市面上很多框架将Harness的功能与Agent核心深度耦合这虽然开箱即用但也失去了灵活性。我们的设计原则是松耦合Harness通过清晰的接口Interface与Agent核心通信。理论上你可以替换背后的LLM比如从GPT-4换成Claude 3或本地模型或者替换任务规划策略只要它们遵守相同的接口约定。3. Gliding Horse的整体架构设计基于上述理念Gliding Horse的架构可以清晰地分为三层这与搜索热词中提到的“LLM、Agent、RAG、Harness”层级观不谋而合但我们有更具体的划分。3.1 核心三层架构第一层基础设施与数据层Harness Core这是Harness的底座与具体Agent业务逻辑无关。状态管理器采用键值存储如Redis或内存数据库维护会话状态。每个会话有一个唯一ID状态包括对话历史、当前任务目标、已执行步骤列表、环境变量等。我们设计了一个版本化的状态快照机制方便回滚到任意步骤进行调试。工具注册中心一个全局的单例所有可用的工具Skill都在这里注册。每个工具需要提供名称、描述、参数Schema符合JSON Schema、执行函数、以及安全策略如是否允许网络访问、文件读写。Harness在Agent调用前会进行参数校验和安全审查。工作流引擎负责驱动PDCA等循环。它是一个轻量级的状态机根据当前阶段Plan/Do/Check/Act调用相应的Agent组件或评估函数并决定状态跳转。可观测性套件集成日志结构化日志如JSON格式、指标Metrics如任务成功率、平均耗时和分布式追踪Tracing。我们将Agent的每一次LLM调用、工具调用都作为一个Span进行追踪形成完整的调用链便于在Jaeger或Zipkin中可视化。第二层智能体核心层Agent Core这是“马”的大脑依赖于LLM。规划器Planner负责将用户模糊的指令转化为具体的、可执行的任务计划。我们借鉴了Graph of Thoughts的思想让规划器能输出一个有向无环图DAG明确步骤间的依赖关系而不仅仅是线性列表。Harness的工作流引擎会解析并执行这个DAG。推理与执行引擎Reasoner/Executor这是核心中的核心。它接收当前状态和任务步骤决定下一步是进行内部推理还是调用某个工具。我们实现了类似ReActReasoning Acting的范式但将其标准化为Harness可管理的“决策-行动”循环。每次决策都会生成结构化的“动作对象”包含动作类型THINK, ACT, FINISH和详细参数。记忆模块分为短期记忆即当前会话的上下文窗口和长期记忆。长期记忆通过一个向量数据库如Chroma或Weaviate实现也就是常说的RAG检索增强生成部分。Harness负责将任务结果、重要结论向量化并存储并在后续任务中由Agent核心通过Harness查询相关记忆实现知识的积累和复用。第三层接口与集成层Interface Integration这是与外界交互的桥梁。API网关提供统一的RESTful或WebSocket接口接收用户请求创建或关联会话并返回流式或非流式响应。网关还负责身份认证、限流和负载均衡。技能Skills集市这是工具的具体实现集合。我们将技能分为基础技能如计算器、时间查询、网络技能安全的HTTP请求、专业领域技能如针对我们业务的“能碳管理数据分析”、“报告生成”。每个技能都是一个独立的、可插拔的模块。客户端与UI我们为内部测试开发了一个简单的Web界面可以实时看到Agent的思考过程、工具调用和状态变化极大提升了调试效率。3.2 技术栈选型背后的思考为什么这么选这里分享一些实操心得编程语言我们选择了Python作为主力。热词里有人问“用Java还是Python”。对于AI Agent项目Python生态LangChain、LlamaIndex、各种ML库的丰富度是压倒性的。快速原型、集成各类AI模型和工具Python是首选。但这不意味着Harness的核心服务不能用Go或Java写高性能组件我们计划未来将状态管理等模块用Go重写以提升并发性能。LLM选择核心推理我们目前使用GPT-4 API因为它规划能力强、稳定性高。但对于一些成本敏感或需要内部部署的场景我们同时接入了开源模型如Qwen、DeepSeek通过Harness的抽象层可以无缝切换。关键点Harness定义了统一的LLM调用接口屏蔽了不同供应商API的差异。向量数据库我们选了Chroma因为它轻量、易嵌入适合初期快速迭代。如果数据量极大可以考虑Pinecone或Weaviate这类云服务。工作流引擎我们没有用Airflow或Prefect这样的重型工具而是自己实现了一个轻量级状态机。因为Agent的工作流步骤更动态、更细粒度重型工作流引擎太重了。自己写反而能更好地与Agent的决策循环PDCA结合。实操心得架构设计初期一定要明确Harness和Agent的边界。我们的经验是凡是与“控制”、“管理”、“保障”相关的放入Harness凡是与“思考”、“决策”、“生成”相关的放入Agent Core。这个界限清晰了后续的开发和调试会顺畅很多。4. 核心环节一PDCA循环的工程化实现PDCA计划-执行-检查-处理循环是一个经典的管理方法论我们将其深度融入Harness作为驱动Gliding Horse执行复杂任务的“主循环”。这不是一个概念上的套用而是实实在在的工程实现。4.1 Plan计划阶段从模糊指令到可执行DAG用户输入“帮我分析上季度A工厂的能耗数据找出异常点并生成一份摘要报告。”传统的Agent可能直接开始“思考”如何调用工具。但在我们的Harness管理下会先强制进入Plan阶段。任务解析与澄清Harness会先调用Agent的“规划器”要求其输出一个初步的任务分解。规划器基于LLM可能会先反问“您指的是哪个具体的上季度例如2024年Q1报告需要包含哪些具体指标电耗、水耗、碳排放对‘异常点’的定义有标准吗如超出历史均值20%”生成结构化计划在获得必要信息可能通过多轮交互后规划器需要输出一个结构化的计划文档格式是Harness定义好的JSON Schema。这个计划不是文本段落而是一个包含步骤列表的JSON对象每个步骤有id步骤ID、description描述、dependencies依赖的步骤ID列表、required_tools可能需要的工具、success_criteria成功标准。{ goal: 分析2024年Q1 A工厂能耗数据并生成报告, steps: [ {id: S1, description: 从数据库获取2024年Q1 A工厂的原始能耗数据, deps: [], tools: [query_database], criteria: 成功获取数据表}, {id: S2, description: 计算各能源类型的月度消耗总量与均值, deps: [S1], tools: [python_calculator], criteria: 计算出数值结果}, {id: S3, description: 基于历史数据过去8个季度识别当前季度数据的统计异常点, deps: [S2], tools: [statistics_analyzer], criteria: 输出异常点列表及置信度}, {id: S4, description: 根据分析结果起草一份包含主要发现和建议的文本报告, deps: [S3], tools: [report_generator], criteria: 生成结构完整的报告草稿}, {id: S5, description: 将报告草稿格式化为Markdown文档, deps: [S4], tools: [formatter], criteria: 生成格式良好的.md文件} ] }计划审核与确认Harness可以可选地将这个计划呈现给用户进行确认或者根据预设的规则进行自动审核例如检查是否有循环依赖、所需工具是否可用。只有确认后才会进入Do阶段。这个阶段的关键价值它迫使Agent进行“慢思考”产出可验证、可追溯的计划。当任务失败时我们能快速定位是计划本身不合理S2步骤的计算逻辑错误还是执行出了问题。4.2 Do执行阶段在Harness监督下的安全运行Harness的工作流引擎会按照计划DAG的拓扑顺序执行步骤。每个步骤的执行都是一个标准的“Agent决策循环”Harness将当前步骤描述、依赖步骤的输出结果、以及当前全局状态组装成提示词Prompt发给Agent核心。Agent核心进行推理决定下一步动作思考、调用工具、或返回结果。如果决定调用工具Harness会拦截这个调用请求。它会校验参数检查传入的参数是否符合工具注册时定义的Schema。安全检查根据该工具的安全策略决定是否放行。例如一个标记为allow_network_access: false的工具试图发起HTTP请求Harness会直接拒绝并返回错误。执行与超时控制在安全的子进程或沙箱环境中执行工具并设置超时时间防止工具卡死。记录与审计详细记录调用的输入、输出、耗时和任何错误信息。工具执行结果返回给Agent核心Agent核心将其纳入上下文进行下一轮推理直到该步骤的success_criteria被满足或达到最大尝试次数。Harness在这里扮演了“监工”和“保镖”的角色。它确保了执行过程是受控的、安全的、可观测的。4.3 Check检查阶段自动化的质量门禁一个步骤或整个计划执行完毕后不会直接进入下一步。Harness会启动Check阶段。结果验证Harness调用预先为这个步骤或任务定义的“检查器”Checker。检查器可以很简单比如验证工具返回的JSON结构也可以很复杂比如调用另一个LLM来评估生成报告的逻辑连贯性和数据准确性。与成功标准比对将验证结果与Plan阶段定义的success_criteria进行比对。例如S3步骤的成功标准是“输出异常点列表及置信度”检查器会验证输出是否包含这两个字段且置信度是否为数值。生成检查报告Check阶段会产生一个明确的通过/失败结论以及详细的检查日志。4.4 Act处理阶段基于反馈的动态调整根据Check的结果Harness决定下一步走向这就是Act。通过任务或步骤标记为完成工作流引擎推进到下一个待执行步骤。失败这里又有多种策略由Harness的策略配置决定自动重试可能是工具调用临时失败Harness可以自动重试几次。计划调整如果失败原因是计划不切实际比如依赖的数据不存在Harness可以触发一个“重新规划”的子流程让Agent核心基于当前已知的失败信息调整后续计划可能跳过某些步骤或增加新的数据获取步骤。人工介入对于关键任务或多次重试失败Harness可以暂停任务通过API或UI向人类操作员发送告警等待指令。优雅失败记录错误保存当前所有上下文和状态然后终止任务并给出清晰的失败原因。PDCA循环的工程化使得Gliding Horse具备了强大的容错和自适应能力。它不再是一个“一杆子捅到底”的脆弱流程而是一个可以自我检查、自我修正的稳健系统。5. 核心环节二技能Tools/Skills系统的设计与安全Agent的强大与否很大程度上取决于它有多少“技能”。但技能的管理和调用安全是Harness的重中之重。5.1 技能的标准化定义我们为每个技能定义了一个标准的描述类以Python为例class Skill: name: str # 唯一标识如 query_database description: str # 给LLM看的自然语言描述 parameters_schema: dict # JSON Schema定义输入参数 function: callable # 实际执行的函数 safety_policy: SafetyPolicy # 安全策略对象 class SafetyPolicy: allow_network_access: bool False allow_file_write: bool False allowed_domains: List[str] [] # 网络访问白名单 max_execution_time: int 30 # 超时时间秒 resource_limits: dict {} # CPU/内存限制5.2 安全沙箱机制对于高风险技能如执行任意代码、写入文件Harness提供了不同级别的隔离级别一参数过滤与校验最基本的利用parameters_schema进行严格校验防止SQL注入、命令注入等。级别二进程隔离使用Python的subprocess模块在独立进程中运行技能并设置资源限制resource_limits。级别三容器化隔离高级对于极度不信任或需求环境纯净的技能Harness可以动态启动一个Docker容器来运行它任务结束后立即销毁容器。这需要集成Docker SDK。我们踩过的一个坑早期我们有一个“执行Python代码片段”的技能只做了简单的eval结果一次Agent在尝试解决数学问题时生成的代码片段里包含了import os; os.system(rm -rf /tmp/*)。虽然因为权限问题没删成但吓出一身冷汗。后来我们立刻改为使用restrictedpython这类沙箱库并默认在无网络、无文件写入权限的隔离环境中执行。5.3 技能的动态发现与组合Harness维护一个技能注册中心。这带来了两个好处动态发现Agent核心在规划时可以从Harness查询当前所有可用技能的描述从而“知道”自己能做什么。这比将技能列表硬编码在Prompt里更灵活支持热更新。技能组合Harness可以支持“元技能”Meta-Skill的创建。例如一个“数据获取与分析”的元技能内部可能按顺序调用了query_database、python_calculator、statistics_analyzer三个基础技能但对Agent核心来说它只是一个技能。这提高了抽象层级让Agent能处理更复杂的原子任务。6. 核心环节三状态管理与可观测性Agent本质上是有状态的。一次复杂的任务可能涉及几十轮LLM调用和工具调用没有可靠的状态管理就像让一个失忆的人完成多步骤项目不可能成功。6.1 状态数据结构设计我们的状态对象是一个深度嵌套的字典但核心部分结构化{ session_id: uuid, user_goal: 原始用户目标, current_phase: PLAN|DO|CHECK|ACT, # PDCA当前阶段 plan: {...}, # 当前生效的计划DAG execution_trace: [ # 执行轨迹按时间顺序记录每一步 { step_id: S1, timestamp: ..., action: TOOL_CALL, tool_name: query_database, input: {...}, output: {...}, error: null, metrics: {duration_ms: 120, tokens_used: 150} }, # ... 更多记录 ], context_memory: { # 当前会话的上下文用于喂给LLM conversation_history: [...], intermediate_results: {S1: {...}}, # 步骤产出物 variables: {quarter: 2024Q1, factory: A} }, long_term_memory_session_id: ... # 关联的长期记忆会话ID }Harness负责这个状态对象的持久化例如每执行完一个动作就保存到Redis、版本化便于调试时回滚和提供给Agent核心作为输入。6.2 可观测性让黑盒变灰盒LLM和Agent常被称为“黑盒”但通过Harness的埋点我们努力让它变成“灰盒”。结构化日志所有关键操作LLM调用开始/结束、工具调用、状态变更、错误都输出为JSON日志方便用ELKElasticsearch, Logstash, Kibana或Loki进行聚合和查询。指标监控我们使用Prometheus暴露了多项指标agent_tasks_total任务总数。agent_tasks_duration_seconds任务耗时分布。llm_calls_total,llm_tokens_usedLLM调用次数和token消耗。tool_calls_total{statussuccess|error}工具调用成功/失败计数。session_active_count当前活跃会话数。 这些指标通过Grafana展示让我们对系统负载、成本、健康度一目了然。分布式追踪这是调试复杂任务链的利器。我们为每个用户请求生成一个Trace ID贯穿整个Harness和Agent核心。每一次LLM调用、每一个工具调用都是一个Span。最终在Jaeger UI上你能看到一个完整的、带有时序和耗时的调用树哪个步骤慢了、失败了清清楚楚。一个真实的调试案例有一次一个生成报告的任务异常缓慢。查看指标发现平均耗时激增。通过追踪我们迅速定位到是“数据查询”工具的一个Span耗时极长。进一步查日志发现是数据库连接池耗尽导致工具调用排队。如果没有这套可观测体系我们可能要在代码里漫无目的地加日志了。7. 开发、测试与部署实践7.1 开发环境与工具链版本控制Git是必须的代码仓库结构清晰Harness、Agent Core、Skills作为独立模块或子目录。本地开发我们使用VS Code配合 Python 虚拟环境。热词里有人问“VS Code怎么导入AI Agent”其实没那么复杂。对于Gliding Horse这样的项目你只需要打开项目根目录VS Code会自动识别Python环境。关键是要配置好.vscode/launch.json来调试不同的组件比如可以单独启动Harness的API服务或者运行一个测试用的Agent会话。技能开发每个技能都是一个独立的Python文件或包通过装饰器或注册函数向Harness注册。开发新技能时我们要求必须同时编写单元测试验证功能和“安全测试”验证在恶意输入下的行为。7.2 测试策略如何测试一个非确定性的Agent测试AI Agent是挑战因为LLM的输出具有非确定性。我们的策略是分层测试单元测试测试Harness的各个组件状态管理器、工具调用器、检查器。这些是确定性代码完全可以用常规的pytest覆盖。技能测试测试每个工具技能给定固定输入验证输出是否符合预期。集成测试Mock LLM在测试环境中将真正的LLM调用替换为Mock服务。这个Mock服务根据输入的Prompt返回我们预先设定好的、确定性的响应。这样我们可以测试整个Harness驱动的PDCA流程是否能按预期走通。例如Mock一个规划器响应看Harness能否正确解析并生成计划DAG。端到端测试有限场景在预发布环境中使用真实的LLM但可能是较便宜的模型如GPT-3.5-Turbo针对一组固定的、高价值的用户场景进行测试。我们主要评估的是流程的鲁棒性而不是输出的绝对内容。例如测试“生成报告”任务是否能走完PDCA全流程而不崩溃至于报告文笔可以设定一个可接受的下限。模糊测试与安全测试用各种奇怪的、恶意的输入去“攻击”Agent检查Harness的安全策略是否能有效拦截系统是否会崩溃或泄露信息。7.3 部署与运维容器化Harness的核心服务、每个技能如果需要独立环境都打包成Docker镜像。编排使用Kubernetes进行编排部署。Harness的API服务是无状态的可以水平扩展。状态管理器Redis和向量数据库作为有状态服务单独部署。配置管理所有配置如LLM API密钥、数据库连接串、安全策略开关都通过环境变量或配置中心管理绝不硬编码。持续集成/持续部署通过GitLab CI/CD代码合并后自动运行测试套件通过后自动构建镜像并部署到测试环境。生产环境部署需要手动触发。8. 常见问题与排查技巧实录在开发Gliding Horse的过程中我们遇到了无数坑。这里分享几个典型问题和解决思路希望能帮你节省时间。8.1 Agent陷入循环或“鬼打墙”现象Agent反复执行相似操作无法推进任务比如不停地查询同一个数据。原因状态管理错误Agent没有正确感知到上一步已成功或者成功状态没有被更新到上下文中。提示词设计缺陷没有在Prompt中清晰告知Agent当前步骤和已完成步骤。工具输出格式不稳定工具返回的数据格式每次略有不同导致Agent解析失败误认为任务未完成而重试。排查与解决检查执行轨迹首先查看Harness记录的execution_trace看步骤是否在重复。如果重复检查重复步骤的输入是否完全相同。审查上下文查看发给LLM的完整Prompt确认历史对话和中间结果是否被正确包含。有时上下文窗口满了历史信息被截断导致Agent“失忆”。标准化工具输出强制要求所有工具返回结构化的JSON并确保Schema稳定。Harness可以在工具返回后先进行一次格式清洗和标准化再交给Agent。设置最大重试次数在Harness的步骤配置中为每个步骤设置最大重试次数比如3次超过后强制失败并进入Act阶段的“人工介入”流程。8.2 工具调用耗时过长拖垮整个任务现象某个工具如一个慢速的外部API调用经常超时导致任务卡住。解决配置超时在工具的safety_policy中务必设置合理的max_execution_time。异步调用Harness可以将工具调用设计为异步非阻塞模式。即发起调用后Harness保存状态并挂起当前会话等工具回调后再唤醒Agent继续。这需要更复杂的状态机但能极大提高并发能力。引入熔断与降级如果某个工具连续失败或超时Harness可以暂时将其标记为“不可用”并在一定时间内让Agent尝试替代方案或直接返回降级结果如缓存数据。8.3 成本失控LLM调用费用飙升现象Token消耗远超预期尤其是处理长文档或复杂规划时。解决精细化上下文管理Harness需要智能管理上下文窗口。不是把所有历史都塞进去。可以采用“摘要”或“关键信息提取”的方式将冗长的历史对话或工具输出压缩成简短的要点后再放入上下文。分层使用模型规划阶段使用能力强但贵的模型如GPT-4执行阶段中简单的工具调用决策或文本润色可以使用能力稍弱但便宜的模型如GPT-3.5-Turbo。Harness可以根据任务阶段动态选择模型。设置预算与配额在Harness层面为每个用户或每个会话设置Token消耗上限或API调用次数上限。达到阈值后Harness可以暂停任务并通知用户。8.4 “幻觉”导致错误工具调用或危险操作现象Agent“幻想”出一个不存在的工具并尝试调用或者对现有工具产生错误理解导致危险参数。解决工具描述优化给工具的description字段下功夫。描述要极其精确、无歧义并包含清晰的输入输出示例。可以在Prompt中强调“你只能调用以下列表中的工具”。Harness严格校验这是最后也是最关键的防线。无论Agent输出什么调用请求Harness必须严格执行两步1) 检查工具名是否在注册中心存在2) 用parameters_schema验证参数格式和类型。任何一步失败立即拒绝并返回错误给Agent让其重新思考。沙箱隔离如前所述对高风险操作进行物理隔离。开发自己的AI Agent和Harness是一个系统工程远不止调通一个Prompt那么简单。它涉及软件架构、安全工程、运维监控等多个领域。Gliding Horse项目对我们团队来说不仅是一个可用的智能体更是一次对AI应用工程化范式的深度探索。这套Harness理念让我们在面对千变万化的业务需求时有了一个坚实、可控、可扩展的基础。如果你也厌倦了在别人的框架里“戴着镣铐跳舞”不妨从设计自己的“缰绳”开始真正驾驭AI这匹强大的“骏马”。 从零构建可控AI Agent：Gliding Horse项目中的Harness设计与工程实践
1. 项目概述为什么我们需要自己的“滑翔马”最近AI Agent智能体这个概念火得不行感觉是个技术大会不提Agent就落伍了。铺天盖地的框架、平台和“一站式解决方案”看得人眼花缭乱从AutoGPT到LangChain再到各种云服务商推出的Agent服务似乎谁都能帮你快速“组装”一个智能体。但作为一个在一线折腾了十多年的老码农我总感觉哪里不对劲。这些框架确实降低了门槛但它们往往也预设了路径封装了“黑箱”你按照它的模板填参数、写提示词最后出来的Agent可能能跑但你很难说清楚它内部每一步决策的逻辑更别提针对自己独特的业务场景进行深度定制和性能调优了。这就好比给你一辆组装好的赛车你能开但你想换个更适合山路的悬挂或者调整一下引擎的进排气却发现无从下手。所以当团队提出要做一个代号为“Gliding Horse”滑翔马的AI Agent项目时我的第一反应是兴奋而不是畏惧。我们不想再当框架的“调参侠”而是想从第一性原理出发理解Agent运作的每一个环节并打造一套属于我们自己的、高度可控的“缰绳”与“鞍具”——这就是我们内部称之为Agent Harness的核心理念。Gliding Horse不是另一个通用Agent框架它是我们为解决特定领域复杂任务而设计的专用智能体而Agent Harness则是确保这匹“马”能听话、高效、稳健奔跑的基础设施层。今天我就来拆解一下Gliding Horse的设计细节尤其是Harness层的构建思路希望能给那些不想盲目跟风希望真正掌握Agent开发主动权的朋友们一些启发。2. 核心理念拆解Harness不是Agent而是它的“操作系统”在开始聊技术细节前必须厘清一个关键概念Agent Harness 和 AI Agent 核心Core Agent是两回事。这是很多初学者甚至一些项目容易混淆的地方。AI Agent核心是什么你可以把它想象成这匹“马”的大脑和本能。它基于大语言模型LLM具备理解、规划、推理和执行的能力。它的核心职责是接收任务拆解任务调用工具Tools/Skills并根据反馈调整策略最终完成任务。这是一个“智能”的部分负责产生意图和决策。Agent Harness又是什么它不是马的大脑而是缰绳、鞍具、蹄铁、导航系统和健康监测仪的总和。它是一套包裹在AI Agent核心推理逻辑之外的基础设施层。Harness不负责代替Agent做决策那是LLM的活它的核心使命是管理、约束、保障和优化Agent的行为。具体来说Harness要解决以下问题生命周期管理Agent的启动、暂停、恢复、销毁。你不能让一匹马乱跑需要能随时叫停它。状态与上下文管理在复杂的多轮对话和任务链中准确维护对话历史、中间结果、工具调用状态。这好比骑手的记忆和马匹的体力记录。工具Skill的注册、发现与安全调用Harness需要提供一个安全沙箱让Agent能可靠地调用外部工具如搜索API、数据库操作、代码执行同时防止危险操作。这是给马匹套上安全的“衔铁”和“护腿”。流程与工作流控制引入如PDCAPlan-Do-Check-Act这样的管理循环或者SMARTSpecific, Measurable, Achievable, Relevant, Time-bound原则来框定任务目标。Harness负责驱动这个循环确保Agent的执行不偏离轨道。例如在“Plan”阶段Harness可以要求Agent输出可验证的计划步骤在“Check”阶段Harness可以自动评估结果并决定是重试、调整还是报错。可观测性Observability与调试实时记录Agent的思考过程Chain-of-Thought、工具调用详情、耗时、token消耗等并提供可视化界面。当Agent行为异常时你能像汽车技师读OBD数据一样快速定位问题。这是给马匹安装的“运动传感器”和“黑匣子”。资源与成本控制监控和管理API调用次数、token消耗避免预算失控。持久化与持久记忆将重要的会话状态、学习到的经验保存下来供下次任务使用。所以Harness更像是一个轻量级的、为Agent定制的“操作系统”或“运行时环境”。一个强大的Harness能让一个中等能力的Agent核心比如一个合适的开源模型发挥出远超其本身水平的稳定表现。而我们开发Gliding Horse很大程度上是在精心打造这个Harness层。注意市面上很多框架将Harness的功能与Agent核心深度耦合这虽然开箱即用但也失去了灵活性。我们的设计原则是松耦合Harness通过清晰的接口Interface与Agent核心通信。理论上你可以替换背后的LLM比如从GPT-4换成Claude 3或本地模型或者替换任务规划策略只要它们遵守相同的接口约定。3. Gliding Horse的整体架构设计基于上述理念Gliding Horse的架构可以清晰地分为三层这与搜索热词中提到的“LLM、Agent、RAG、Harness”层级观不谋而合但我们有更具体的划分。3.1 核心三层架构第一层基础设施与数据层Harness Core这是Harness的底座与具体Agent业务逻辑无关。状态管理器采用键值存储如Redis或内存数据库维护会话状态。每个会话有一个唯一ID状态包括对话历史、当前任务目标、已执行步骤列表、环境变量等。我们设计了一个版本化的状态快照机制方便回滚到任意步骤进行调试。工具注册中心一个全局的单例所有可用的工具Skill都在这里注册。每个工具需要提供名称、描述、参数Schema符合JSON Schema、执行函数、以及安全策略如是否允许网络访问、文件读写。Harness在Agent调用前会进行参数校验和安全审查。工作流引擎负责驱动PDCA等循环。它是一个轻量级的状态机根据当前阶段Plan/Do/Check/Act调用相应的Agent组件或评估函数并决定状态跳转。可观测性套件集成日志结构化日志如JSON格式、指标Metrics如任务成功率、平均耗时和分布式追踪Tracing。我们将Agent的每一次LLM调用、工具调用都作为一个Span进行追踪形成完整的调用链便于在Jaeger或Zipkin中可视化。第二层智能体核心层Agent Core这是“马”的大脑依赖于LLM。规划器Planner负责将用户模糊的指令转化为具体的、可执行的任务计划。我们借鉴了Graph of Thoughts的思想让规划器能输出一个有向无环图DAG明确步骤间的依赖关系而不仅仅是线性列表。Harness的工作流引擎会解析并执行这个DAG。推理与执行引擎Reasoner/Executor这是核心中的核心。它接收当前状态和任务步骤决定下一步是进行内部推理还是调用某个工具。我们实现了类似ReActReasoning Acting的范式但将其标准化为Harness可管理的“决策-行动”循环。每次决策都会生成结构化的“动作对象”包含动作类型THINK, ACT, FINISH和详细参数。记忆模块分为短期记忆即当前会话的上下文窗口和长期记忆。长期记忆通过一个向量数据库如Chroma或Weaviate实现也就是常说的RAG检索增强生成部分。Harness负责将任务结果、重要结论向量化并存储并在后续任务中由Agent核心通过Harness查询相关记忆实现知识的积累和复用。第三层接口与集成层Interface Integration这是与外界交互的桥梁。API网关提供统一的RESTful或WebSocket接口接收用户请求创建或关联会话并返回流式或非流式响应。网关还负责身份认证、限流和负载均衡。技能Skills集市这是工具的具体实现集合。我们将技能分为基础技能如计算器、时间查询、网络技能安全的HTTP请求、专业领域技能如针对我们业务的“能碳管理数据分析”、“报告生成”。每个技能都是一个独立的、可插拔的模块。客户端与UI我们为内部测试开发了一个简单的Web界面可以实时看到Agent的思考过程、工具调用和状态变化极大提升了调试效率。3.2 技术栈选型背后的思考为什么这么选这里分享一些实操心得编程语言我们选择了Python作为主力。热词里有人问“用Java还是Python”。对于AI Agent项目Python生态LangChain、LlamaIndex、各种ML库的丰富度是压倒性的。快速原型、集成各类AI模型和工具Python是首选。但这不意味着Harness的核心服务不能用Go或Java写高性能组件我们计划未来将状态管理等模块用Go重写以提升并发性能。LLM选择核心推理我们目前使用GPT-4 API因为它规划能力强、稳定性高。但对于一些成本敏感或需要内部部署的场景我们同时接入了开源模型如Qwen、DeepSeek通过Harness的抽象层可以无缝切换。关键点Harness定义了统一的LLM调用接口屏蔽了不同供应商API的差异。向量数据库我们选了Chroma因为它轻量、易嵌入适合初期快速迭代。如果数据量极大可以考虑Pinecone或Weaviate这类云服务。工作流引擎我们没有用Airflow或Prefect这样的重型工具而是自己实现了一个轻量级状态机。因为Agent的工作流步骤更动态、更细粒度重型工作流引擎太重了。自己写反而能更好地与Agent的决策循环PDCA结合。实操心得架构设计初期一定要明确Harness和Agent的边界。我们的经验是凡是与“控制”、“管理”、“保障”相关的放入Harness凡是与“思考”、“决策”、“生成”相关的放入Agent Core。这个界限清晰了后续的开发和调试会顺畅很多。4. 核心环节一PDCA循环的工程化实现PDCA计划-执行-检查-处理循环是一个经典的管理方法论我们将其深度融入Harness作为驱动Gliding Horse执行复杂任务的“主循环”。这不是一个概念上的套用而是实实在在的工程实现。4.1 Plan计划阶段从模糊指令到可执行DAG用户输入“帮我分析上季度A工厂的能耗数据找出异常点并生成一份摘要报告。”传统的Agent可能直接开始“思考”如何调用工具。但在我们的Harness管理下会先强制进入Plan阶段。任务解析与澄清Harness会先调用Agent的“规划器”要求其输出一个初步的任务分解。规划器基于LLM可能会先反问“您指的是哪个具体的上季度例如2024年Q1报告需要包含哪些具体指标电耗、水耗、碳排放对‘异常点’的定义有标准吗如超出历史均值20%”生成结构化计划在获得必要信息可能通过多轮交互后规划器需要输出一个结构化的计划文档格式是Harness定义好的JSON Schema。这个计划不是文本段落而是一个包含步骤列表的JSON对象每个步骤有id步骤ID、description描述、dependencies依赖的步骤ID列表、required_tools可能需要的工具、success_criteria成功标准。{ goal: 分析2024年Q1 A工厂能耗数据并生成报告, steps: [ {id: S1, description: 从数据库获取2024年Q1 A工厂的原始能耗数据, deps: [], tools: [query_database], criteria: 成功获取数据表}, {id: S2, description: 计算各能源类型的月度消耗总量与均值, deps: [S1], tools: [python_calculator], criteria: 计算出数值结果}, {id: S3, description: 基于历史数据过去8个季度识别当前季度数据的统计异常点, deps: [S2], tools: [statistics_analyzer], criteria: 输出异常点列表及置信度}, {id: S4, description: 根据分析结果起草一份包含主要发现和建议的文本报告, deps: [S3], tools: [report_generator], criteria: 生成结构完整的报告草稿}, {id: S5, description: 将报告草稿格式化为Markdown文档, deps: [S4], tools: [formatter], criteria: 生成格式良好的.md文件} ] }计划审核与确认Harness可以可选地将这个计划呈现给用户进行确认或者根据预设的规则进行自动审核例如检查是否有循环依赖、所需工具是否可用。只有确认后才会进入Do阶段。这个阶段的关键价值它迫使Agent进行“慢思考”产出可验证、可追溯的计划。当任务失败时我们能快速定位是计划本身不合理S2步骤的计算逻辑错误还是执行出了问题。4.2 Do执行阶段在Harness监督下的安全运行Harness的工作流引擎会按照计划DAG的拓扑顺序执行步骤。每个步骤的执行都是一个标准的“Agent决策循环”Harness将当前步骤描述、依赖步骤的输出结果、以及当前全局状态组装成提示词Prompt发给Agent核心。Agent核心进行推理决定下一步动作思考、调用工具、或返回结果。如果决定调用工具Harness会拦截这个调用请求。它会校验参数检查传入的参数是否符合工具注册时定义的Schema。安全检查根据该工具的安全策略决定是否放行。例如一个标记为allow_network_access: false的工具试图发起HTTP请求Harness会直接拒绝并返回错误。执行与超时控制在安全的子进程或沙箱环境中执行工具并设置超时时间防止工具卡死。记录与审计详细记录调用的输入、输出、耗时和任何错误信息。工具执行结果返回给Agent核心Agent核心将其纳入上下文进行下一轮推理直到该步骤的success_criteria被满足或达到最大尝试次数。Harness在这里扮演了“监工”和“保镖”的角色。它确保了执行过程是受控的、安全的、可观测的。4.3 Check检查阶段自动化的质量门禁一个步骤或整个计划执行完毕后不会直接进入下一步。Harness会启动Check阶段。结果验证Harness调用预先为这个步骤或任务定义的“检查器”Checker。检查器可以很简单比如验证工具返回的JSON结构也可以很复杂比如调用另一个LLM来评估生成报告的逻辑连贯性和数据准确性。与成功标准比对将验证结果与Plan阶段定义的success_criteria进行比对。例如S3步骤的成功标准是“输出异常点列表及置信度”检查器会验证输出是否包含这两个字段且置信度是否为数值。生成检查报告Check阶段会产生一个明确的通过/失败结论以及详细的检查日志。4.4 Act处理阶段基于反馈的动态调整根据Check的结果Harness决定下一步走向这就是Act。通过任务或步骤标记为完成工作流引擎推进到下一个待执行步骤。失败这里又有多种策略由Harness的策略配置决定自动重试可能是工具调用临时失败Harness可以自动重试几次。计划调整如果失败原因是计划不切实际比如依赖的数据不存在Harness可以触发一个“重新规划”的子流程让Agent核心基于当前已知的失败信息调整后续计划可能跳过某些步骤或增加新的数据获取步骤。人工介入对于关键任务或多次重试失败Harness可以暂停任务通过API或UI向人类操作员发送告警等待指令。优雅失败记录错误保存当前所有上下文和状态然后终止任务并给出清晰的失败原因。PDCA循环的工程化使得Gliding Horse具备了强大的容错和自适应能力。它不再是一个“一杆子捅到底”的脆弱流程而是一个可以自我检查、自我修正的稳健系统。5. 核心环节二技能Tools/Skills系统的设计与安全Agent的强大与否很大程度上取决于它有多少“技能”。但技能的管理和调用安全是Harness的重中之重。5.1 技能的标准化定义我们为每个技能定义了一个标准的描述类以Python为例class Skill: name: str # 唯一标识如 query_database description: str # 给LLM看的自然语言描述 parameters_schema: dict # JSON Schema定义输入参数 function: callable # 实际执行的函数 safety_policy: SafetyPolicy # 安全策略对象 class SafetyPolicy: allow_network_access: bool False allow_file_write: bool False allowed_domains: List[str] [] # 网络访问白名单 max_execution_time: int 30 # 超时时间秒 resource_limits: dict {} # CPU/内存限制5.2 安全沙箱机制对于高风险技能如执行任意代码、写入文件Harness提供了不同级别的隔离级别一参数过滤与校验最基本的利用parameters_schema进行严格校验防止SQL注入、命令注入等。级别二进程隔离使用Python的subprocess模块在独立进程中运行技能并设置资源限制resource_limits。级别三容器化隔离高级对于极度不信任或需求环境纯净的技能Harness可以动态启动一个Docker容器来运行它任务结束后立即销毁容器。这需要集成Docker SDK。我们踩过的一个坑早期我们有一个“执行Python代码片段”的技能只做了简单的eval结果一次Agent在尝试解决数学问题时生成的代码片段里包含了import os; os.system(rm -rf /tmp/*)。虽然因为权限问题没删成但吓出一身冷汗。后来我们立刻改为使用restrictedpython这类沙箱库并默认在无网络、无文件写入权限的隔离环境中执行。5.3 技能的动态发现与组合Harness维护一个技能注册中心。这带来了两个好处动态发现Agent核心在规划时可以从Harness查询当前所有可用技能的描述从而“知道”自己能做什么。这比将技能列表硬编码在Prompt里更灵活支持热更新。技能组合Harness可以支持“元技能”Meta-Skill的创建。例如一个“数据获取与分析”的元技能内部可能按顺序调用了query_database、python_calculator、statistics_analyzer三个基础技能但对Agent核心来说它只是一个技能。这提高了抽象层级让Agent能处理更复杂的原子任务。6. 核心环节三状态管理与可观测性Agent本质上是有状态的。一次复杂的任务可能涉及几十轮LLM调用和工具调用没有可靠的状态管理就像让一个失忆的人完成多步骤项目不可能成功。6.1 状态数据结构设计我们的状态对象是一个深度嵌套的字典但核心部分结构化{ session_id: uuid, user_goal: 原始用户目标, current_phase: PLAN|DO|CHECK|ACT, # PDCA当前阶段 plan: {...}, # 当前生效的计划DAG execution_trace: [ # 执行轨迹按时间顺序记录每一步 { step_id: S1, timestamp: ..., action: TOOL_CALL, tool_name: query_database, input: {...}, output: {...}, error: null, metrics: {duration_ms: 120, tokens_used: 150} }, # ... 更多记录 ], context_memory: { # 当前会话的上下文用于喂给LLM conversation_history: [...], intermediate_results: {S1: {...}}, # 步骤产出物 variables: {quarter: 2024Q1, factory: A} }, long_term_memory_session_id: ... # 关联的长期记忆会话ID }Harness负责这个状态对象的持久化例如每执行完一个动作就保存到Redis、版本化便于调试时回滚和提供给Agent核心作为输入。6.2 可观测性让黑盒变灰盒LLM和Agent常被称为“黑盒”但通过Harness的埋点我们努力让它变成“灰盒”。结构化日志所有关键操作LLM调用开始/结束、工具调用、状态变更、错误都输出为JSON日志方便用ELKElasticsearch, Logstash, Kibana或Loki进行聚合和查询。指标监控我们使用Prometheus暴露了多项指标agent_tasks_total任务总数。agent_tasks_duration_seconds任务耗时分布。llm_calls_total,llm_tokens_usedLLM调用次数和token消耗。tool_calls_total{statussuccess|error}工具调用成功/失败计数。session_active_count当前活跃会话数。 这些指标通过Grafana展示让我们对系统负载、成本、健康度一目了然。分布式追踪这是调试复杂任务链的利器。我们为每个用户请求生成一个Trace ID贯穿整个Harness和Agent核心。每一次LLM调用、每一个工具调用都是一个Span。最终在Jaeger UI上你能看到一个完整的、带有时序和耗时的调用树哪个步骤慢了、失败了清清楚楚。一个真实的调试案例有一次一个生成报告的任务异常缓慢。查看指标发现平均耗时激增。通过追踪我们迅速定位到是“数据查询”工具的一个Span耗时极长。进一步查日志发现是数据库连接池耗尽导致工具调用排队。如果没有这套可观测体系我们可能要在代码里漫无目的地加日志了。7. 开发、测试与部署实践7.1 开发环境与工具链版本控制Git是必须的代码仓库结构清晰Harness、Agent Core、Skills作为独立模块或子目录。本地开发我们使用VS Code配合 Python 虚拟环境。热词里有人问“VS Code怎么导入AI Agent”其实没那么复杂。对于Gliding Horse这样的项目你只需要打开项目根目录VS Code会自动识别Python环境。关键是要配置好.vscode/launch.json来调试不同的组件比如可以单独启动Harness的API服务或者运行一个测试用的Agent会话。技能开发每个技能都是一个独立的Python文件或包通过装饰器或注册函数向Harness注册。开发新技能时我们要求必须同时编写单元测试验证功能和“安全测试”验证在恶意输入下的行为。7.2 测试策略如何测试一个非确定性的Agent测试AI Agent是挑战因为LLM的输出具有非确定性。我们的策略是分层测试单元测试测试Harness的各个组件状态管理器、工具调用器、检查器。这些是确定性代码完全可以用常规的pytest覆盖。技能测试测试每个工具技能给定固定输入验证输出是否符合预期。集成测试Mock LLM在测试环境中将真正的LLM调用替换为Mock服务。这个Mock服务根据输入的Prompt返回我们预先设定好的、确定性的响应。这样我们可以测试整个Harness驱动的PDCA流程是否能按预期走通。例如Mock一个规划器响应看Harness能否正确解析并生成计划DAG。端到端测试有限场景在预发布环境中使用真实的LLM但可能是较便宜的模型如GPT-3.5-Turbo针对一组固定的、高价值的用户场景进行测试。我们主要评估的是流程的鲁棒性而不是输出的绝对内容。例如测试“生成报告”任务是否能走完PDCA全流程而不崩溃至于报告文笔可以设定一个可接受的下限。模糊测试与安全测试用各种奇怪的、恶意的输入去“攻击”Agent检查Harness的安全策略是否能有效拦截系统是否会崩溃或泄露信息。7.3 部署与运维容器化Harness的核心服务、每个技能如果需要独立环境都打包成Docker镜像。编排使用Kubernetes进行编排部署。Harness的API服务是无状态的可以水平扩展。状态管理器Redis和向量数据库作为有状态服务单独部署。配置管理所有配置如LLM API密钥、数据库连接串、安全策略开关都通过环境变量或配置中心管理绝不硬编码。持续集成/持续部署通过GitLab CI/CD代码合并后自动运行测试套件通过后自动构建镜像并部署到测试环境。生产环境部署需要手动触发。8. 常见问题与排查技巧实录在开发Gliding Horse的过程中我们遇到了无数坑。这里分享几个典型问题和解决思路希望能帮你节省时间。8.1 Agent陷入循环或“鬼打墙”现象Agent反复执行相似操作无法推进任务比如不停地查询同一个数据。原因状态管理错误Agent没有正确感知到上一步已成功或者成功状态没有被更新到上下文中。提示词设计缺陷没有在Prompt中清晰告知Agent当前步骤和已完成步骤。工具输出格式不稳定工具返回的数据格式每次略有不同导致Agent解析失败误认为任务未完成而重试。排查与解决检查执行轨迹首先查看Harness记录的execution_trace看步骤是否在重复。如果重复检查重复步骤的输入是否完全相同。审查上下文查看发给LLM的完整Prompt确认历史对话和中间结果是否被正确包含。有时上下文窗口满了历史信息被截断导致Agent“失忆”。标准化工具输出强制要求所有工具返回结构化的JSON并确保Schema稳定。Harness可以在工具返回后先进行一次格式清洗和标准化再交给Agent。设置最大重试次数在Harness的步骤配置中为每个步骤设置最大重试次数比如3次超过后强制失败并进入Act阶段的“人工介入”流程。8.2 工具调用耗时过长拖垮整个任务现象某个工具如一个慢速的外部API调用经常超时导致任务卡住。解决配置超时在工具的safety_policy中务必设置合理的max_execution_time。异步调用Harness可以将工具调用设计为异步非阻塞模式。即发起调用后Harness保存状态并挂起当前会话等工具回调后再唤醒Agent继续。这需要更复杂的状态机但能极大提高并发能力。引入熔断与降级如果某个工具连续失败或超时Harness可以暂时将其标记为“不可用”并在一定时间内让Agent尝试替代方案或直接返回降级结果如缓存数据。8.3 成本失控LLM调用费用飙升现象Token消耗远超预期尤其是处理长文档或复杂规划时。解决精细化上下文管理Harness需要智能管理上下文窗口。不是把所有历史都塞进去。可以采用“摘要”或“关键信息提取”的方式将冗长的历史对话或工具输出压缩成简短的要点后再放入上下文。分层使用模型规划阶段使用能力强但贵的模型如GPT-4执行阶段中简单的工具调用决策或文本润色可以使用能力稍弱但便宜的模型如GPT-3.5-Turbo。Harness可以根据任务阶段动态选择模型。设置预算与配额在Harness层面为每个用户或每个会话设置Token消耗上限或API调用次数上限。达到阈值后Harness可以暂停任务并通知用户。8.4 “幻觉”导致错误工具调用或危险操作现象Agent“幻想”出一个不存在的工具并尝试调用或者对现有工具产生错误理解导致危险参数。解决工具描述优化给工具的description字段下功夫。描述要极其精确、无歧义并包含清晰的输入输出示例。可以在Prompt中强调“你只能调用以下列表中的工具”。Harness严格校验这是最后也是最关键的防线。无论Agent输出什么调用请求Harness必须严格执行两步1) 检查工具名是否在注册中心存在2) 用parameters_schema验证参数格式和类型。任何一步失败立即拒绝并返回错误给Agent让其重新思考。沙箱隔离如前所述对高风险操作进行物理隔离。开发自己的AI Agent和Harness是一个系统工程远不止调通一个Prompt那么简单。它涉及软件架构、安全工程、运维监控等多个领域。Gliding Horse项目对我们团队来说不仅是一个可用的智能体更是一次对AI应用工程化范式的深度探索。这套Harness理念让我们在面对千变万化的业务需求时有了一个坚实、可控、可扩展的基础。如果你也厌倦了在别人的框架里“戴着镣铐跳舞”不妨从设计自己的“缰绳”开始真正驾驭AI这匹强大的“骏马”。