仅凭裸模型存在四大局限：缺乏记忆、无法执行代码、知识陈旧、没有工作环境。Harness通过六大组件逐一解决——文件系统负责存储与版本管理；沙箱环境赋予代码自我验证能力；AGENTS.md无需训练即可注入知识；Web Search与MCP打破知识的时间壁垒；上下文工程对抗信息熵增；编排系统与Hooks保障多智能体协作质量。贯穿始终的系统提示词，则是整套框架的神经中枢。

核心观点在于：模型提供原始智能，而Harness则让智能变得切实可用。如果你并非模型本身，那么你很可能正在构建或使用Harness的一部分。

2025年底，一位创业者在社交媒体上分享的经历迅速引发了技术圈的广泛讨论：

“我花了三个月优化Prompt，模型回答质量提升了20%。然后我花了两周搭建Harness，整体任务完成率从35%飙升到了82%。” 这条动态下，点赞最高的评论仅四个字：方向错了。

过去两年，整个行业似乎都在追逐更庞大的模型、更强的推理能力和更长的上下文窗口。从GPT-4到Claude 3.5，从Gemini Ultra到DeepSeek-V3，参数规模不断刷新纪录，基准测试分数持续攀升。每一次新模型发布，都会掀起一阵“通用人工智能即将到来”的乐观情绪。

然而，一个不容忽视的事实是：在绝大多数真实业务场景中，用户并未感受到与基准分数相匹配的能力跃升。

原因何在？或许是因为关注的焦点出现了偏差。

模型如同一台强大的引擎，但引擎本身并非汽车。一台裸露的引擎放置在地面，它无法载人、无法转向、无法制动，甚至无法自行启动。你需要底盘、变速箱、方向盘、仪表盘、燃油系统……这一整套让引擎“发挥作用”的装备，在AI智能体的世界中，正逐渐被赋予一个日益重要的名称——Harness。

智能体 = 模型 + Harness。 模型负责提供智能，Harness则负责让智能落地产生价值。

这并非一个全新的概念，但它正在成为2026年AI工程领域最核心的共识。本文将从“裸模型的四个硬伤”切入，逐一剖析Harness的六大核心组件——文件系统、Bash与沙箱、记忆系统（AGENTS.md）、Web搜索与MCP、上下文工程、编排与Hooks——旨在揭示AI智能体真正的竞争壁垒并不在模型层，而在Harness层。

阅读本文后，你将重新认识一个事实：你所编写的每一行系统提示词、搭建的每一个工具链、设计的每一套协作逻辑，都是在构建Harness。如果你不是模型本身，那么你就是Harness的一部分。

Agent = Model + Harness：一个被忽视太久的公式

在深入拆解Harness之前，我们有必要先确立一个基础的认知框架。

什么是 Agent？

“Agent”一词在2024年被过度使用。任何能调用API的聊天机器人都自称Agent，任何增加了RAG的问答系统都宣称自己是Agent。但若回归其最本质的定义—— Agent是一个能够自主感知环境、做出决策、执行行动并从结果中学习的智能体。

请注意其中的四个关键动词：感知、决策、执行、学习。裸模型能胜任哪一步？严格来说，它仅能完成“决策”——给定输入，产生输出。它无法主动感知外部世界（缺乏感官），不能真正执行行动（缺乏手脚），更无法进行持久化的学习（缺乏长期记忆）。

因此，一个真正的Agent必然是这样的结构： Agent = Model + Harness

Model是大脑，负责“思考”。Harness则是大脑之外的一切——感官系统、运动系统、记忆系统、能量系统——负责将“思考”转化为“行动”。

Harness 到底是什么？

Harness的英文原意为“挽具”，即套在马上、将马力转化为拉车动力的那套装备。这个类比十分精妙：模型是马，Harness是挽具，而Agent是马、挽具与车辆构成的完整系统。

更技术化地描述，Harness是模型之外的所有工程基础设施的集合。它至少包括：

• 模型如何接收输入（上下文构建）
• 模型的输出如何被解析与执行（工具调用、代码执行）
• 模型如何获取外部信息（搜索、API调用）
• 模型如何记住过往经历（记忆机制）
• 模型如何与其他模型或子系统协作（编排）
• 以及贯穿所有环节的安全、格式与质量约束（Hooks）

Harness不是一个单一的零件，而是一套系统工程。这也解释了为何构建一个真正高效的Agent如此困难——你并非在调整某个参数，而是在设计一整座工程架构。

这张图传达了三个核心信息：第一，Model虽处于中心，但被Harness全方位包围与支撑；第二，六大组件各司其职又相互协同；第三，系统提示词（System Prompt）贯穿所有组件，是Harness的“神经系统”。

裸模型的四个硬伤：为什么光有聪明的大脑远远不够

要理解Harness的价值，必须先正视一个现实：裸模型（Raw Model）存在四个致命的缺陷。

所谓“裸模型”，即没有任何外部工具、文件系统、搜索能力或持久化记忆的纯粹大语言模型。可以将其想象为一个被关在密闭房间里的天才——智商极高，但看不见外界，记不住昨天的对话，发出的指令也无人执行。

硬伤一：无法维持跨会话状态

这是最易被感知的痛点。你与一个裸模型进行了两小时深度对话，讨论了一个复杂的系统架构，绘制了流程图，确定了技术方案。然后你关闭窗口，次日返回——它已忘记了一切。

这并非“记忆力差”，而是根本没有记忆机制。裸模型的每一次对话都是全新的开始，前一轮的所有上下文在会话结束时即刻消失。

对于简单问答，这或许无妨。但对于任何需要持续推进的工作——撰写书籍、开发项目、管理流程——此缺陷是致命的。你需要每次都从头解释背景，重新建立共识，手动输入之前的结论。这并非在与AI协作，而是在训练一位每日失忆的实习生。

硬伤二：无法执行代码

裸模型可以“编写”代码，但不能“运行”代码。它可以生成一段Python脚本，却无法验证这段代码是否能正确执行。它可以告诉你算法的时间复杂度，但不能在真实数据集上运行一遍以证明其分析。

这意味着什么？意味着裸模型的代码输出缺乏自我验证能力。它可能写出语法正确但逻辑错误的代码，可能忽略边界条件，可能对库版本做出错误假设。而所有这些错误，只有在人类手动复制代码到本地环境运行后才会暴露。

更深层的问题是：缺乏代码执行能力，模型便失去了“编写→运行→观察→修复→迭代”的自我验证循环。此循环正是优秀程序员的核心工作方式。一个不能运行自身代码的AI编程助手，犹如一位只会在纸上绘图却从不踏足工地的建筑师——理论上完美，实践中漏洞百出。

硬伤三：无法获取实时知识

大语言模型的知识存在一个“截止日期”。截止日期之后的一切——新发布的API文档、最新的安全漏洞、上周刚更新的框架版本、今日新闻——它一无所知。

在技术领域，此问题尤为严重。前端框架每半年一次大版本更新，云服务商每季度调整产品线，开源库的不兼容变更防不胜防。你询问裸模型“React 19的use() Hook如何使用”，它可能给出基于React 18的答案，甚至虚构一个根本不存在的API。

这正是所谓“幻觉”（Hallucination）的一个重要来源：模型并非“故意”胡说，而是其知识库中根本没有正确答案，于是它基于过时信息或模式匹配，“推理”出一个看似合理实则错误的答案。

在AI领域保持前沿，需要持续跟进层出不穷的新概念。不久前，“Token”的中文译名刚被正式确定为“词元”，眼下又一个亟待厘清的新术语“Harness”进入了大众视野。

这年头想要在AI圈子里当个“全面发展的专业人士”，每天要学习的概念是真的多。从最早一个ChatGPT能指代一切AI，到后来逐步厘清Prompt是“提示词”还是“文令”、了解已显颓势的MCP（模型上下文协议）正被CLI替代、掌握风靡一时的RAG（检索增强生成）技术、明确Agent应译为“智能体”而非“代理”、知晓Skills既是“技能”也代表“专家”、以及认识Claude Code这类代码助手。

还有因“Claw”（爪子）得名的OpenClaw、以及因模型处理需求激增而被反复讨论的Token……这些堪比“颗粒度”、“对齐”的行业术语，如果你都有所涉猎，大概率能在一些探讨AI的场合中稍展学识。

如今，新的术语已然到来——何为Harness？有网友在社交媒体上用一张淘宝搜索结果截图进行回应，表示其“很好理解”。

虽然看似离谱，但若将AI视作可被驱使的“牛马”，将Harness翻译为套在AI身上的“马具”或“束缚”，也并非全无道理。事实上，Harness被正式引入智能体领域，可追溯至Anthropic去年十一月发布的一篇博客。文中探讨了当前智能体所需执行的任务日益延长，因而需要一个有效的Harness来确保其运作正常。

进入今年，随着本地化运行的智能体再度成为焦点，众多AI开发者与研究员在其技术博客中也频繁提及Harness一词。知名博主Mitchell Hashimoto提出了“Harness Engineering”的理念，其核心是：“每当发现某个智能体犯错时，就投入时间设计一个解决方案，确保它未来不再犯同样的错误。”

紧随其后，OpenAI在今年二月发布的数篇博客同样聚焦于Harness engineering。在他们看来，未来工程师的职责或许不再是编写代码，而是设计智能体的“工作环境”，而Harness正是这个环境本身。

二、为何Harness概念日益重要

无论是Anthropic最初的论述，还是后来OpenAI倡导的Harness工程，其核心叙事是一致的。

Harness是一个集环境配置、多智能体协作机制、严格架构约束与上下文管理于一体的系统性框架，旨在弥补AI存在的“上下文焦虑”与易错性缺陷。

两家顶尖AI实验室均通过大量的内部工程实践证实，让大模型自主编写数百万行代码的关键，并不完全在于模型本身的智能程度，更在于是否构建了一个强大的Harness（可理解为工作流框架或护栏系统）。

我们让Claude生成了一张示意图来完整阐述Agent Harness的概念。简而言之，Harness = 智能体的运行容器 + 安全边界 + 调度控制器。

在Anthropic的内部实验中，研究人员意外地发现AI也可能存在“心理问题”。当Claude执行长周期编码任务时，一旦感知到自身的上下文窗口即将被填满，它便会产生“上下文焦虑”。这好比临近下班的打工人，开始草率应付，急于结束手头工作。

棘手的是，Claude自身并不认为这是在敷衍。当研究员要求AI评估这些“为赶工而编写”的代码时，它无法识别其中存在的问题。面对此类状况，传统的提示词工程往往收效甚微。Anthropic研究员提出的Harness解决方案是：重构任务的组织架构。

他们设计了一个包含三个角色的Harness闭环系统：

• 规划师：负责将一句模糊的需求扩展为详尽的产品需求文档。
• 生成器：纯粹的执行者，仅依据文档编写代码。
• 评估器：严格的质检员兼产品经理，手握自动化测试工具，冷酷无情。

Anthropic的报告指出，应用了Harness框架的智能体在生成网页质量上显著提升，尽管付出了更高的成本与时间代价。例如，在开发一个游戏制作器的任务中：

• 未使用Harness的小组：耗时20分钟，花费9美元。结果是界面尚可，但核心功能损坏——游戏角色无法响应键盘操作。
• 使用Harness的小组：耗时6小时，花费200美元。结果是一个功能完备的游戏，包含动画系统、音效甚至AI辅助的关卡设计。

在这套体系中，生成器每完成一段代码，评估器便会像真实用户一样进行点击与测试。一旦发现Bug或设计平庸之处，便立即打回重做。在另一项设计荷兰艺术博物馆网页的任务中，前9次迭代AI都产出着常规网页。但在评估器的持续压力下，第10次迭代AI突破了模板，交付了一个独特的3D空间设计，让画作悬挂于透视棋盘格房间中，用户需以穿梭迷宫的方式浏览。

如果说Anthropic的Harness侧重于通过组织架构探索设计原理，那么OpenAI的Codex团队则是将此事提升为一种工程文化，更多地视Harness为一种工作流框架。

他们的核心约束非常明确：不写入工代码。所有代码——包括业务逻辑、测试用例、CI配置、文档、内部工具乃至监控仪表盘——均由Codex生成。工程师的职责转变为设计能让AI可靠工作的环境。

初期，他们尝试用一个超长的AGENTS.md文件来告知AI所有规则，但很快因上下文限制导致AI只能进行浅层的模式匹配，且文档难以维护而过时。后来的改进方案是：AGENTS.md仅保留100行作为“目录”，将AI引导至结构化的docs/文件夹。所有架构文档、产品规格等均由AI编写和维护，并有专门的“文档园丁”智能体定期扫描更新。

他们不干涉AI编写具体逻辑，但在Harness中设定了极其严格的Linter（代码检查工具）和物理依赖边界。业务代码必须单向调用，越界行为会被系统阻断，无法合并入主分支。在这个体系中，人类设定的规则成为AI不可违背的意志。AI如同生活在“楚门的世界”，拥有编写代码的充分自由，但这种自由永远被限定在人类设定的Harness结界之内。

综合这些研究，Harness的本质是一套系统性补偿机制，用以弥补当前AI的诸多短板：

• 针对不擅长的长期记忆：Harness利用进度文件、Git历史、结构化文档来补充。
• 针对过于宽松的自我评价：引入独立的评估智能体，配备具体标准和真实环境测试。
• 针对复杂任务中的易偏航性：通过任务分解、结构化约束和合约约定来限定范围。
• 针对缺乏代码库架构的直觉：借助文档化和自动化规范检查，将人类的判断转化为系统规则。

一个有趣的现象是，随着模型能力增强，Harness的某些部分可能变得不再必要，但新的需求又会产生。Anthropic在升级到Opus 4.6模型后，发现之前为对抗“上下文焦虑”设计的“上下文重置”机制可以直接移除，因为新模型已能自行处理。但同时，他们发现了新方向——利用Harness让AI在应用中自动集成AI功能，这是此前模型做不到的。对Harness而言，模型越强大，Harness的目标不是变得更简单，而是要去应对更艰巨的挑战。

三、Harness中文译名探讨：从“线束”到“不翻译”

在关于“继Token、Agent之后，又来了一个难以翻译的词：Harness”的讨论下，除了那张令人印象深刻的“战术胸带”截图，网友们也提出了诸多译名方案。

有人主张沿用汽车行业的成熟译法“线束”。其他提议包括“驾驭层”、“驾驭系统”、“智能体框架”、“控制框架”、“管控层”、“锚定层”，乃至认为其等同于“Scaffold（脚手架）”。更有趣的提议如“安全套”、“套马杆”，以及约束行为的“槽具”。

微博上关于Harness译法的讨论也很热烈。有观点认为，若Token可译为“智元”，那Harness或可称“智驭”。也有人觉得，如同现今少人问津的MCP，Harness概念可能只是一时之热，很快又会有新词涌现。

我们询问了Claude的看法，它给出了多个选项：“框架”过于宽泛；“执行框架”强调了运行层面但缺乏“约束”感；“驾驭层”在中文技术语境中不常见；“管控层”突出了“约束”但缺失“执行”意味；“套具”在AI领域则完全陌生。

因此，Claude最终倾向于一个实用方案：不翻译，直接使用“Harness”原词。

一个概念若能精准对应一个词语，翻译本是水到渠成。Harness之所以难以定译，是因为它在LLM工作流中，同时涵盖了“约束”、“执行”、“环境”、“系统”等多重内涵，拆分出的任何一个译名都只能表述其部分含义。正如Token最终被确定为“词元”，Harness大概率也将迎来其官方的中文译名。在那之前，当你在技术文献中邂逅此词，理解其指代何物便已足够。

未来，在某个谈及AI的场合，或许可以这样总结：“在未来，精通提示词或技能设计可能不再是核心竞争力。真正的顶尖人才，将是那些深谙如何设计Harness的人。”

延伸阅读资料：

1. Anthropic, 《适用于长时间运行应用程序开发的Harness设计》，2026-03-24
2. OpenAI, 《Harness工程：在智能体优先的世界中利用Codex》，2026-02-11
3. Mitchell Hashimoto, 《我的AI应用之旅》，2026-02-05
4. OpenAI, 《解锁Codex的Harness：我们如何构建App Server》，2026-02-04
5. Anthropic, 《适用于长期运行Agents的有效Harness》，2025-11-26

Harness：让Agent成为可控、可纠错的“任务完成器”

Harness一词，其本意是马具——一种用于引导和控制马匹行动的装置。它的核心价值不在于提升马匹的奔跑速度，而在于确保马匹能够朝着正确的方向，并以一种可控、可预测的方式前进。

将这一概念引入到Agent开发领域，harness 指的是那些让智能体变得更加透明、可控且具备自我纠错能力的工程方法与框架。其根本目标，是将一个原本如同“黑盒随机生成器”般不可预测的大型语言模型智能体，约束和塑造为一个能够稳定、可靠完成任务的工作系统。

换言之，harness 工程所关注的核心问题并非“如何让模型变得更聪明”，而是致力于解决以下挑战：

• 如何让智能体的决策过程不再完全不可知。
• 如何在智能体犯错的当下，系统能够及时检测并触发纠正机制。
• 如何确保智能体的所有行动始终紧密围绕并推进最终的任务目标。
• 如何为智能体设定清晰、合理的边界，使其在完成任务后适时停止。

最终，我们期望中的Agent不应再像一个无法驾驭的随机过程，而应转变为一个被精心设计的框架所引导和约束的、高效的 任务完成器。

Harness工程背后的核心思路

为了实现上述目标，OpenAI和Anthropic等领先机构基于自身实践，总结出了一些颇具指导性的经验。仔细审视这些经验，会发现它们与人类在传统软件工程领域积累的诸多原则高度契合。本质上，Harness工程是将软件开发中那些久经考验的成熟实践，创造性地迁移并应用到了LLM智能体系统的构建中。这些思路包括：

• 为执行者（Agent）提供清晰、定义完备的操作环境和工具集。
• 设计系统，使其内部状态易于被观察、监控和解读。
• 依赖外部、客观的反馈机制来判断任务结果，而非依赖模型的“自我感觉”。
• 将复杂的宏观任务拆解为由不同角色协同的、职责明确的执行流程。
• 利用详尽的日志记录、清晰的状态管理和明确的业务规则来约束整个执行过程。

OpenAI的建议：让环境与反馈来约束Agent

OpenAI的思路更侧重于工程系统本身的设计。其核心思想可以被概括为一句话：与其耗费大量精力反复打磨提示词，不如优先为Agent设计一个结构良好、反馈清晰的工作环境。

环境设计优于提示词打磨

对于智能体而言，真正至关重要的并非一段“更精巧”的提示语，而是它能否实时、准确地感知其所处“世界”的状态，并能在该环境中有效执行动作、获得反馈。

一个更适合Agent工作的优质环境，通常包含以下基础设施：

• 结构化的文件系统视图
• 可供调用的、功能明确的可执行工具（API）
• 用于验证结果的自动化测试用例
• 记录每一步操作的日志系统
• 监控关键性能与状态的度量指标系统

这其实与人类开发者的工作模式异曲同工。开发者并非仅凭一段需求描述（如同提示词）工作，而是高度依赖集成开发环境、命令行终端、单元测试、日志输出和性能监控等一整套基础设施，来持续确认“当前进度如何”、“上一步做了什么”以及“下一步该做什么”。LLM Agent同样如此，如果没有一个设计良好的环境提供稳定的状态输入和动作反馈，即使模型能力再强，也极易陷入“基于不完整信息盲目猜测”的困境。

输出应对Agent友好：追求结构化与可解析性

如果希望智能体能够持续、自主地运行，且不轻易中断其执行循环，那么环境反馈给它的信息就必须足够清晰、易于解析。

例如，以下这种结构化的错误输出就远比一句模糊的自然语言描述更适合Agent处理：

{
  "status": "failed",
  "error_type": "missing_dependency",
  "file": "auth.py",
  "line": 42
}

相比之下，模糊的输出如“build fail error line 42”则对机器不友好。

结构化输出的优势在于：

• Agent可以直接进行解析，无需额外的理解或猜测。
• 更容易形成自动化的反馈-处理闭环。
• 为后续的重试机制、分支决策和状态追踪提供了便利的数据基础。

本质上，非结构化的输出容易破坏Agent的事件处理循环，迫使它停下来进行“理解”；而结构化输出则能让系统维持在一个更流畅、连续的运转状态中。

以测试作为客观判断依据，将“正确性”验证外包

OpenAI提出的另一项重要建议是：不要让LLM自身来主观判断任务结果是否合格，而应将“正确性”的最终裁决权交给外部系统来客观验证。

最典型且有效的方式便是引入自动化测试：

• 单元测试：验证代码模块的独立功能。
• 集成测试：验证多个模块协同工作的整体表现。

这种做法意义深远。它意味着Agent不再依赖其内部生成的、可能带有偏见的“自我评价”来宣布任务完成，而是必须直面现实系统（测试套件）给出的、客观的“是/否”反馈。

判断标准从而发生了根本性转变，从主观的 “我认为这段代码应该可行” ，转变为客观的 “所有测试用例均已通过，因此当前结果被系统判定为可接受” 。这一步至关重要，因为它将Agent的行为有效性，从“语言层面的逻辑自洽”拉回到了“现实世界中的功能可验证”。

强制建立短反馈循环，让每一步都获得校准

OpenAI还强调，应避免让Agent进行长时间的、脱离反馈的“闭门造车”式规划，然后一次性执行大量步骤。相反，系统应被设计成促使Agent进入一种更短促、更紧密的反馈循环。

理想的工作模式是：

• Agent执行一个小步幅的动作。
• 环境立即返回该动作的结果或状态变化。
• Agent根据这个即时反馈，修正或确认下一步的行动计划。

这意味着系统应形成这样的循环：动作 -> 反馈 -> 校准 -> 新动作， 而非 长时间规划 -> 一次性执行多步 -> 最终才发现方向性错误。

前置知识提示： 了解大型语言模型（LLM）的基本原理、ReAct推理模式，并拥有AI智能体（如AutoGPT、Claude Code或Cursor Agent）的使用经验。
核心观点： 模型本身正逐渐成为标准化商品，而Harness所代表的基础设施层才是构建竞争护城河的关键。

一、Harness的精确定义：模型与执行的桥梁

智能体 = 模型 + Harness

模型专注于“思考”过程，负责生成语言标记（token）；Harness则承担“执行”职责，将这些标记转化为实际动作——例如读取文件、调用应用程序接口（API）、执行代码或持久化保存状态。

如果将模型比喻为一匹拥有蛮力的野马，那么Harness就是驾驭它的缰绳与鞍具，将原始力量导向可控、高效的工作输出。另一个更为精确的类比是：模型如同中央处理器（CPU），Harness则是操作系统（OS）。CPU负责执行计算指令，而操作系统管理着所有外围资源与调度。没有操作系统的裸机CPU，甚至无法点亮屏幕。

LangChain工程师Vivek Trivedi给出了一个极为简洁的定义：

如果你不是模型本身，那么你所做的一切就属于Harness的范畴。

换言之，除了模型权重参数之外，所有促使智能体运转起来的代码、配置、流程逻辑，统统归属于Harness这一层。

二、为何仅凭模型不足以应对生产环境

大型语言模型的核心本质是：接收输入标记，并生成输出标记。它天生缺乏以下关键能力：

上述每一种能力缺口，都是Harness需要填补和构建的基础设施空白。

三、核心架构剖析：Harness的层次化组件

Harness并非单一工具，而是一套按功能分层的能力模块集合。

🧠 LLM（智能层）

⚙️ Harness（框架层）

💾 文件系统与持久化存储 + 工作空间管理

💻 Bash/代码执行 + 通用工具与自定义工具集成

🛡️ 沙箱环境 + 隔离执行与安全边界设定

📋 记忆与检索系统 + 跨会话记忆与实时知识接入

💡 规划与验证模块 + 目标分解与自验证循环

🔗 钩子与中间件 + 上下文压缩与流程拦截续接

推理引擎 → 输入提示词 → 输出动作指令

3.1 文件系统：持久化能力的基石

这是最底层、也是最关键的原始能力（primitive）。模型仅能操作其上下文窗口内的数据。缺乏文件系统，智能体就像没有笔记本的人——对话内容随风而逝，关闭会话窗口便全部遗忘。

智能体框架（Harness）到底是什么？它并非一个简单的包装，而是构建功能化人工智能的核心基础设施。本文将深入拆解其构成与价值。

智能体框架的本质：模型与框架的分离

首先，我们可以用一个简洁的公式来概括智能体的核心构成：智能体 = 模型 + 框架。如果你正在构建的不是模型本身，那么你工作的重点就是框架。这个划分虽然基础，却蕴含着深刻的设计哲学。

所谓框架（Harness），指的是除基础模型之外的一切组件，包括运行代码、配置参数、执行逻辑与状态管理。一个未经“装配”的原始模型并非智能体，它仅仅是一个能够生成文本的“大脑”。只有当框架为其注入状态管理、工具调用、反馈循环以及各类约束条件后，它才真正转变为一个能够执行具体任务的智能体。

具体而言，一个典型的框架包含以下要素：系统提示词、可供调用的工具与技能（例如 MCP 协议及其描述）、捆绑的基础设施（如文件系统、沙箱环境、浏览器）、任务编排逻辑（如子代理生成、任务交接、模型路由选择），以及确保执行确定性的各类钩子与中间件（例如上下文压缩、任务延续、代码检查）。

清晰划分模型与框架的边界，其最大益处在于迫使系统设计者围绕模型的核心智能进行思考，避免将模型能力与实现框架混为一谈，从而构建出更清晰、更可维护的系统架构。

框架存在的必要性：弥补大模型的固有局限

要理解框架为何不可或缺，需从大模型自身的局限性说起。基础模型的功能本质上相当纯粹：接收文本、图像、音频或视频作为输入，并输出相应的文本。仅此而已。

开箱即用的模型无法独立完成以下事项：在多次交互中维持持久化的状态、执行任意代码、访问实时更新的信息、或自行配置环境并安装依赖包。所有这些能力，都需要在框架层面进行设计和实现。

一个最直观的例子便是日常使用的“聊天”应用。其本质是将模型包裹在一个循环结构中，记录并管理对话历史，然后追加新的消息进行交互。这本身就是一种最基础的框架形态。其核心设计思路在于：将期望的智能体行为，翻译并实现在框架的具体功能之中。

文件系统：框架最底层的基石

核心需求：赋予智能体持久化存储的能力，使其能够与真实数据交互，将无法放入上下文的信息卸载存储，并实现跨会话的工作成果保存。

模型的认知边界严格受限于其上下文窗口，除此之外它不拥有任何持久记忆。在没有文件系统支持的情况下，用户必须手动将内容复制粘贴到上下文中，这对于追求自主性的智能体而言是完全不可行的。

解决方案自然而直接：由框架提供一套文件系统抽象以及相应的文件操作工具。文件系统堪称最基础的框架“原语”，它解锁了几项关键能力：智能体拥有了专属的工作空间，可以读取数据、代码和文档；工作可以增量式写入并卸载，无需将所有内容都塞入有限的上下文；状态能够跨越不同的会话得以持久保存；多个智能体与用户之间可以通过共享文件进行协作——那些“智能体团队”架构正是基于此运行。

在文件系统之上叠加 Git 等版本控制工具，智能体便能够追踪工作进度、回滚错误操作、开辟分支进行实验。因此，文件系统不仅仅是存储介质，它更是后续所有高级能力得以构建的坚实地基。

Bash 与代码执行：解锁通用问题解决能力

核心需求：让智能体具备自主解决问题的能力，而非每次都需要用户为其预先设计好每一个专用工具。

当前智能体的主流执行模式是 ReAct（推理-行动）循环：推理下一步该做什么，调用工具执行，观察结果，并循环往复。问题在于，如果仅提供一组固定的预定义工具，智能体的能力上限便被牢牢锁死。

与其要求用户为每一种可能的操作编写专用工具，不如直接赋予智能体一个 Bash 工具，让它自行编写代码来解决问题。框架集成 Bash 工具，模型通过自主编写和执行代码来应对各种复杂场景。这是让模型“拥有一台电脑”的关键一跃。它不再受限于预配置的工具集，而是能够通过编写代码动态创造出解决问题所需的新工具。当然，框架中仍可包含其他专用工具，但代码执行已成为智能体实现自主问题解决的默认通用策略。

沙箱环境：为安全执行装上防护网

核心需求：为智能体提供一个具备正确默认配置、能够安全执行操作、观察结果并推进任务的环境。

具备了存储和代码执行能力后，还需要一个安全的“场所”来运行这些操作。直接在本地执行智能体生成的代码风险极高，并且单一的本地机器资源也难以支撑大规模的智能体工作负载。

沙箱环境有效解决了这一问题——它为智能体提供了隔离的、安全的执行环境。框架连接到沙箱来运行代码、检查文件、安装依赖、完成任务，而非在本地直接执行。沙箱可以按需动态创建、分发到多个并行任务，并在任务完成后销毁，天然支持系统的横向扩展。

一个优秀的执行环境还需配备良好的默认工具集：预装的语言运行时和常用软件包、用于版本控制和测试的命令行工具、用于网页交互与验证的浏览器。拥有了浏览器、日志记录、屏幕截图、测试运行器等工具后，智能体便能形成自我验证的闭环——编写代码、运行测试、查看日志、修复错误，实现全流程自主化。

智能体在何处运行、拥有哪些工具、能够访问哪些资源、如何验证自身工作成果——所有这些都属于框架层面的设计决策，基础模型本身对此无能为力。

记忆与搜索：赋予智能体持续进化的知识

核心需求：智能体应当能够记住已经学习或处理过的信息，并且能够访问其训练截止日期之后出现的新知识。

模型除了其内部权重和当前的上下文内容外，不存储任何额外的知识。既然无法直接修改模型权重，“添加知识”的唯一途径便是向上下文窗口中注入信息。

文件系统在此再次扮演核心角色。框架可以支持类似 AGENTS.md 这样的记忆文件，在智能体启动时自动将其内容注入上下文。智能体在工作过程中更新这个文件，框架在下次启动时便会加载最新版本——这实现了一种持续学习机制：将某个会话中学到的经验持久化，并带入未来的会话中。

至于知识时效性问题，网络搜索工具和 MCP（模型上下文协议）工具（例如 Context7）能够帮助智能体访问训练数据截止日期之后的信息，例如新版本的库文档、最新的实时数据等。将网络搜索和查询最新上下文的工具作为基础能力直接集成到框架中，是极具价值的。

对抗上下文衰减：高效管理稀缺资源

核心需求：智能体的表现不应随着工作的推进和上下文窗口的填满而显著下降。

上下文衰减描述了一个真实存在的现象：随着上下文窗口逐渐被填满，模型的推理能力和任务完成质量会出现明显下滑。上下文是一种稀缺资源，框架必须实施有效的策略来管理它。

压缩机制用于处理上下文窗口即将耗尽的情况。若无压缩，一旦对话长度超出窗口限制，轻则导致 API 调用错误，重则致使整个任务崩溃。压缩机制能够智能地卸载并总结已有的上下文内容，从而让智能体得以继续工作。

工具调用卸载解决了大型工具输出污染上下文的问题。对于超过特定长度的工具输出结果，框架仅在上下文中保留其开头和结尾部分，完整内容则被卸载到文件系统中，待需要时再行读取。

**技能（Skills）**机制旨在解决工具过载的问题。如果在智能体启动时就将所有可用工具及其 MCP 服务器描述全部加载进上下文，那么工作尚未开始，宝贵的上下文空间便已被占满。技能通过“渐进式披露”来解决此问题——启动时仅加载简要的元数据，当真正需要使用某个特定工具时，再动态展开其详细描述。

长期自主执行：应对复杂挑战的框架策略

核心需求：使智能体能够在较长的时间跨度内，自主且可靠地完成复杂的多步骤任务。

自主软件开发被视为智能体编程的终极目标之一，但现有模型存在几个固有弱点：容易过早停止任务、难以有效分解复杂问题、在跨越多个上下文窗口时表现不一致。一个优秀的框架必须正面应对这些挑战。

在执行长期任务时，前述的基础“原语”可能变得不够用。此时需要更强大的持久状态管理、任务规划、执行观察与结果验证机制，才能在跨越多个上下文窗口的情况下持续推进任务。

文件系统与 Git 集成被用于跨会话追踪任务进度。长时间运行的任务会消耗大量 Token，文件系统将工作状态持久化保存，使得新加入的智能体或新的上下文窗口能够快速接手。对于多个并行工作的智能体而言，文件系统还充当着共享的“任务账本”。

Ralph 循环用于维持工作的持续性。这是一种特定的工具调用模式：通过框架钩子拦截模型意图“退出”或结束任务的企图，在一个全新的、干净的上下文窗口中重新注入原始任务目标，从而“强迫”智能体继续工作。每次迭代都从一个新的上下文开始，但会读取前一次迭代保存在文件系统中的状态——这使得持续的长期任务成为可能。

在日常工作和生活中，我们时常会遇到需要使用特定软件功能的情况，而许多优质工具往往需要付费订阅。为了方便，不少人选择直接支付费用，但这实际上可能是一笔可以节省的开销。

事实上，许多付费软件的核心功能，都能找到出色的免费替代品。这些免费的在线工具不仅功能强大，使用便捷，有时甚至能提供超越付费软件的体验。本文将分享10个经过精心挑选和长期使用的在线工具网站。它们无需下载安装，打开浏览器即可直接使用，真正做到“用到就是省到”，建议您收藏备用。

pdfcandy

官网链接： https://pdfcandy.com/cn/

这是一个功能极其全面的PDF处理中心，提供了超过90种免费的在线工具。它支持PDF与Word、Excel、图片等多种格式间的相互转换，允许您直接编辑PDF文件中的文字内容。此外，您还可以轻松地对PDF进行拆分、合并、裁剪页边距等操作，并支持文件加密和解密，甚至具备OCR文字识别功能。网站也提供了桌面版本，方便您在无网络环境下使用。

123APPS

官网链接： https://123apps.com/cn/

这是一个集多功能于一体的实用型在线工具平台，主要涵盖视频、音频、PDF处理和格式转换四大类别。您可以用它来剪辑视频、进行在线录屏、调整音频参数或实现在线录音。其PDF工具集同样强大，支持各类格式转换与文件拆分合并。值得一提的是，它的转换器功能非常全面，能为视频、音频乃至电子书等多种文件进行格式转换。

AI智能文本纠错润色

官网链接： https://www.text-well.com/zh

这是一个基于人工智能的免费文本校对与优化工具。除了提供基础的语法检查、拼写纠错和标点符号修正外，其最大的特色在于“AI评审团”功能。该功能能够从多个不同角度（如表达清晰度、语气、专业性等）对文本提出修改建议。您可以逐项审核这些建议，并有选择地采纳，从而在优化文本的同时，有效避免过度修改，保持您原有的写作风格。

合同模板

官网链接： https://mubanxiazai.cn/

这是一个提供海量免费合同与文书模板的网站。用户无需注册或登录即可直接下载使用。网站资源丰富，涵盖了合同协议、仲裁诉讼文书、通知函、公司制度规范、常用作文模板以及个人简历等多种类型。所有模板均提供可编辑的源文件（如Word格式），下载后您可以根据自身需求进行自由修改。

virscan

官网链接： https://www.virscan.org/

这是一个公益性质的在线恶意文件检测站点，完全免费向公众开放。它集成了数十款国内外知名安全厂商提供的最新病毒检测引擎，支持检测文档、安装程序、压缩包等多种格式的文件（单个文件上限为100MB）。虽然它不能完全替代本地的杀毒软件，但在您需要对来源不明的文件进行快速安全评估时，它是一个非常值得信赖的辅助工具。

在线PS

官网链接： https://www.zaixianps.net/

这是一个高度模仿Adobe Photoshop的在线图片编辑工具。它几乎完整复刻了Photoshop的软件界面与核心功能，操作逻辑相似，上手简单。该工具完全免费，无需安装或注册，支持直接上传和导出PSD格式文件，兼容性极佳。无论是在Windows、Mac电脑，还是iPhone等移动设备上，都能通过浏览器快速访问并使用其强大功能。

pdftolink

官网链接： https://pdftolink.app/zh-hans

这是一个极具巧思的PDF文件分享工具。它的核心功能是将您上传的PDF文件转换为一个可分享的链接。生成链接后，您只需将链接发送给对方，对方即可在线查看PDF内容，无需下载或传输大文件。整个使用过程无需注册，平台会对文件进行加密处理，并支持设置访问密码，有效保障了文件分享的安全性。

filepost

官网链接： https://file-post.net/zc/

这是一个便捷的免费大文件临时分享工具。您可以一次性上传最多10个文件，总大小不超过500MB。使用过程同样无需注册，上传的文件会在服务器上保留最多5天。其用户界面类似于发送电子邮件，允许您填写发件人、收件人（最多3个）和简短消息，系统会自动将文件下载链接通过邮件发送给指定的收件人。

在线证件照制作

官网链接： https://app.xiaoqiyun.cn/idphoto/page1/

这是一个提供免费在线证件照制作服务的工具。它覆盖了多种常用尺寸（如1寸、小1寸、2寸）以及各类考试、求职、签证等特定场景所需的证件照规格。其智能抠图算法较为精细，可以一键替换照片背景底色（如红、蓝、白），方便您快速制作出符合要求的证件照。

codebox

官网链接： https://www.codebox.club/

这是一个功能全面且设计友好的免费在线二维码生成器。它支持生成URL网址、WiFi连接、纯文本等多种类型的二维码，并提供丰富的智能美化选项与短链追踪功能。用户无需注册即可一键生成PNG格式的二维码图片，并可以自由定制二维码的颜色、图案形状、中心Logo以及边框样式。所有生成功能均可用于商业用途，且不限生成次数，全程无水印。

以上推荐的10个网站均为笔者亲自测试并长期收藏的实用工具，它们能有效替代许多付费服务，帮助您节省不必要的开支。建议您将有需要的网站添加至浏览器书签，以便随时取用。

国庆假期即将来临，外出旅行难免人潮拥挤、身心疲惫，而完全宅家躺平又略显单调。综合考量之下，舒舒服服地窝在家里看电影、追剧集，无疑是更为惬意舒适的放松方式。

既然要享受观影追剧的乐趣，一款得心应手的播放工具自然不可或缺。为此，我们精心挑选并实测了几款覆盖macOS、Windows、Android、iOS及智能电视等多个平台的优秀视频播放器，它们各具特色，能满足不同场景下的需求。强烈建议您先行收藏，即便当下用不到，未来也可能派上大用场！

网易爆米花：全平台自动刮削，聚合多网盘资源

作为网易出品的一款集媒体库管理与播放于一体的工具，网易爆米花兼容性极广，几乎支持所有主流操作系统，可在手机、平板、智能电视及电脑上安装使用。目前其功能完全免费开放，且界面清爽无任何广告干扰。

它能够直接挂载并聚合来自阿里云盘、百度网盘、115网盘、天翼云盘、中国移动云盘、123云盘等主流网盘的资源，同时也支持通过WebDAV、SMB协议访问本地网络存储（NAS）或连接Emby媒体库，资源适配范围相当广泛。

将存储于NAS或各类网盘中的视频添加至网易爆米花后，软件可自动进行信息刮削并生成美观的海报墙。不过，其分类方式相对基础，仅分为电影、电视剧和其他三大类，暂不支持按年份、类型等条件进行更精细化的筛选。

在播放能力上，它支持超过200种音视频和字幕编码，能够流畅解码播放4K、HDR等高画质视频。用户可便捷地调整播放倍速，切换内置的字幕、画面模式及音轨。但需要注意的是，它目前仅支持切换视频内封装的音轨和字幕，无法手动添加外挂字幕文件，功能定位偏向于基础实用。

总体而言，网易爆米花的自动刮削功能非常省心，完全免费且能实时同步更新，支持挂载的网盘种类丰富，多设备间的播放记录也能同步。虽然其整体功能和界面设计较为简洁，但考虑到市面上多数刮削工具均需付费，它无疑是一款颇具诚心的良心之作。

当贝播放器：专为智能电视与投影优化

提到“当贝”，许多关注智能电视和投影仪的朋友应该都不陌生。当贝播放器正是当贝为其硬件产品开发的一款专属播放工具，当然，它也可以安装到其他品牌的安卓电视或电视盒子上。这款播放器同样具备视频信息刮削和生成海报墙的功能，并能对剧集进行自动归类整理。

此外，它还提供了在线字幕匹配、局域网共享播放等实用功能。字幕方面支持切换内封、外挂以及在线搜索字幕；视频解码能力强劲，支持超过170种音视频格式，甚至无需解压即可直接播放蓝光原盘的ISO文件或BDMV文件夹目录。

添加视频源的方式也很多样，既支持本地存储设备，也支持接入各类网盘，还能通过DLNA等媒体流协议进行推送。在网盘支持上提供了多个选项，同时也能方便地添加同一局域网内电脑或NAS上的共享文件夹。

不过在实际刮削测试中，其匹配准确度有待提升，存在部分视频信息识别错误或无法识别的情况。特别是对于英文命名的视频文件，刮削出的元数据往往无法自动转化为中文，导致海报墙看起来有些混乱。

要想实现精准的刮削和生成精美的海报墙，用户可能需要进行繁琐的手动修正。尽管如此，若论及在电视端的视频解码能力与流畅度，能够超越当贝播放器的工具并不多见。因此，将其作为一款纯粹的、高性能的本地视频播放器在电视上使用，依然是一个不错的选择。

PotPlayer：Windows平台上专业级播放器标杆

PotPlayer是一款在Windows用户中享有盛誉的视频播放软件。它的界面或许看起来朴实无华，甚至有些简陋，但实际上，它堪称专业级电脑播放器的典范，功能强大且深度可定制。

笔者曾亲历，在电脑上使用其他播放器播放杜比视界（Dolby Vision）格式的片源时，画面会呈现异常的绿色。起初怀疑是播放器问题，更换多款后情况依旧，最终使用PotPlayer播放，色彩表现立即恢复正常，这充分证明了其卓越的解码兼容性。

事实上，PotPlayer支持包括360度全景视频、3D视频在内的几乎所有主流音视频格式。它深度融合了DXVA、CUDA、QuickSync等硬件加速技术，并内置了强大的编解码器，能显著提升高码率视频播放的流畅度与效率，有效降低CPU占用。

此外，PotPlayer提供了极其丰富的自定义选项，用户可以根据个人喜好精细调整各项播放参数。它不仅拥有强大的画面后期处理滤镜（如调整色彩、锐化、去交错等），还配备了一个10波段的专业音频均衡器，允许用户自定义音频输出曲线，以满足发烧友级别的听感需求。

总而言之，这是一款界面简洁但内核无比强大的视频播放器。强烈建议每位Windows用户都在电脑上安装它，不仅是用于日常追剧观影，即便是播放专业设备拍摄的全景视频，它也能完美胜任。

IINA：为macOS而生的优雅开源播放器

尽管macOS系统本身以设计和体验著称，但平台上不少第三方视频播放软件的表现却差强人意，且大多需要付费购买。IINA则是这其中难得的佼佼者，它是一款几乎支持所有主流音视频格式、具备强大解码能力的开源免费播放器，堪称Mac用户的福音。

IINA深度整合了macOS的原生特性，完美支持触控栏（Touch Bar）操作、画中画模式以及音乐播放模式。在其1.4.0及后续版本中，还引入了可扩展的插件体系，增强了可玩性。同时，它支持断点续播功能，可以直接播放本地视频文件或添加网络流媒体服务器地址。

软件内置了视频与音频均衡器，支持手动精细调节。视频播放支持无级倍速调整，并可加载外置音轨文件。其字幕功能尤为强大，不仅允许用户手动校准字幕时间轴，还能便捷地加载外挂字幕文件或直接从网络搜索匹配字幕。

对于字幕的字体、颜色、大小、位置等，均可进行完全自定义设置。在线字幕搜索功能可通过关联OpenSubtitles等账户自动实现。

此外，截图、多文件夹播放列表管理、无限的播放历史记录等实用功能一应俱全。IINA不仅在功能上毫不逊色，操作体验也流畅直观，加之其完全免费开源，无疑是Mac电脑上必装的软件之一。

极影视：NAS用户的终极影音解决方案

对于NAS（网络附加存储）用户而言，极影视是极空间NAS设备内置的专属媒体播放中心。由于极空间官方提供了Windows、macOS、Android、iOS全平台客户端，因此极影视也能实现跨平台使用，并支持多设备间的播放进度同步。在体验极空间NAS之前，笔者主要使用前述几款播放器；但自从用上极空间，极影视便成为了观影追剧的绝对主力。

许多NAS用户会借助Vidhub、Infuse等第三方工具来管理媒体库和播放视频，但设置过程往往较为复杂，且不少高级功能需要额外付费订阅。相比之下，极空间NAS内置的极影视开箱即用，无需额外付费，其在刮削准确度和播放能力上的表现却异常强大。

在极影视中，只需添加存有影视资源的文件夹，它便能自动、精准地刮削影片信息，生成精美的海报墙。支持按画质、上映年份、影片类型等多种维度进行筛选，并能智能识别中英文文件名及文件夹结构，将同一剧集自动归类。除了海报墙，每部影视剧的详情页还会展示主要演职员表和分集剧情简介。

极影视的解码能力同样出众，支持ISO、MKV、BDMV等多种高清蓝光格式，能够完美解码HDR10、HDR10+、杜比视界等高端画质技术。音频方面也全面支持DTS、DTS-HD Master Audio以及杜比全景声的解码。虽然其播放设置的专业丰富程度可能不及PotPlayer，但相较于其他NAS播放工具和大多数通用播放器，其综合体验已属碾压级别。切换音轨、画质、字幕以及调整播放倍速都非常便捷。

对于部分没有内置中文字幕的高画质影片，极影视支持手动添加外挂字幕或在线搜索匹配字幕。用户可以手动调整字幕的时间轴、屏幕上的位置以及颜色样式。更值得一提的是，其“影像处理”功能中的智能字幕生成，可以直接为视频生成中文字幕，虽然并非高频需求，但在观看某些小众或难以找到字幕的资源时，此功能显得尤为实用。

极空间NAS的下载功能也非常强大便捷，内置了迅雷和PT下载工具。不过，笔者更常使用的是其网盘备份功能：先将想看的影视剧转存到网盘，然后通过极空间直接将其下载到NAS中，整个过程自动化，省时省力。

极空间NAS无需借助Alist等第三方工具进行复杂配置，即可直接登录并挂载百度网盘、天翼云盘、移动云盘、夸克网盘、阿里云盘、OneDrive、115网盘等主流网盘，极大简化了操作。以笔者为例，由于不想额外购买会员，主要使用夸克网盘（淘宝88VIP赠送年度会员），虽然普通会员下载存在限速，播放超高码率4K电影可能卡顿，但结合手机端的夸克App进行资源转存，再通过极空间下载到本地，最后在电视、电脑或平板上通过极影视流畅观看，形成了一套完美的观影闭环。

在近期的系统更新后，极影视甚至支持直接刮削和播放已挂载网盘中的影视资源，这样既能利用网盘的存储空间，也能减轻NAS本地硬盘的存储压力，提供了更灵活的资源管理方式。

如果您是一位高频次的影视剧爱好者，配备一台极空间NAS无疑是提升体验的绝佳选择。目前，性能版的极空间Z4Pro+售价在两千多元区间，四盘位的极空间Q4一千多元即可入手，而双盘位的极空间Z2Pro甚至仅需几百元。除了完美解决影音娱乐需求，它们还提供了AI智能相册管理、多系统文件备份等丰富功能。

总结

以上盘点的几款播放器软件均为免费使用，能够满足您在手机、电脑、电视等多平台播放视频的核心需求，并且都具备较强的解码能力。然而，如果论及一站式影音娱乐体验的完整性和便捷度，极空间NAS及其内置的极影视无疑展现出了更高的集成度。它将资源刮削、远程下载、集中存储、多端同步播放、智能字幕搜索等多项功能融为一体，为用户提供了一个真正意义上“all-in-one”的家庭影音解决方案，在体验上确实领先于独立的播放器软件。您可以根据自己的主要使用场景和设备，选择最适合您的工具。

当美的空调在运行中出现异常状况时，最直接的线索往往来自显示屏上闪烁的故障代码。准确识别并理解这些代码，能够帮助您迅速定位问题根源，从而让维修工作变得更有针对性，显著提高效率。

美的空调常见故障代码解析

代码表：E系列、M系列、H系列、G系列直流变频挂机

• E1: 室内机与室外机之间的通讯出现故障。
• E2: 系统在进行过零检测时发生错误。
• E3: 室内风机的转速出现异常，失去控制。
• E4: 温度保险丝因过热而断开，起到保护作用。
• E5: 位于室外的温度传感器发生故障。
• E6: 位于室内的温度传感器发生故障。
• P0: 变频模块触发保护机制。
• P1: 检测到供电电压过高或过低，系统自动保护。
• P2: 压缩机顶部温度过高，触发温度保护。
• P4: 直流变频压缩机的位置检测出现异常。

代码表：N系列、W系列直流变频挂机

• E1: 室内机与室外机通讯异常。
• E2: 过零检测环节出错。
• E3: 风机速度控制失效。
• E4: 温度保险丝断开保护启动。
• E5: 室外温度传感器故障，或室外机EEPROM（可擦写存储器）数据异常。
• E6: 室内温度传感器失效。
• P0: 模块保护被触发。
• P1: 电压超出正常范围，启动保护。
• P2: 压缩机顶部温度保护。
• P4: 直流变频压缩机位置检测故障。

代码表：C系列全直流变频挂机

• E2: 室内外机通讯故障。
• E3: 过零检测错误。
• E4: 风机转速失控。
• E5: 室外温度传感器故障，或室外机E方参数出错。
• E6: 室内温度传感器故障。
• E7: 室外风机转速失控。
• E8: 显示控制板与主控板通讯失败。
• E9: IPM（智能功率模块）出现故障。
• P0: 模块保护。
• P1: 电压过高或过低保护。
• P2: 压缩机顶部温度保护。
• P3: 检测到室外环境温度过低，启动保护。
• P4: 直流变频压缩机位置检测故障。

代码表：I系列直流变频挂机

• E1: 室内外机通讯故障。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E5: 室外温度传感器或E方参数故障。
• E6: 室内温度传感器故障。
• E7: 室外风机速度失控。
• E8: 除尘功能复位时出现故障。
• P0: 模块保护。
• P1: 电压保护。
• P2: 压缩机顶部温度保护。
• P3: 室外温度过低保护。
• P4: 压缩机位置保护。

代码表：J、K、L、R、K（太阳能）系列直流变频挂机

• E1: 室内外机通讯故障。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E5: 室外温度传感器或E方参数故障。
• E6: 室内温度传感器故障。
• E7: 室外风机速度失控。
• E8: 运行模式设置冲突。
• P0: 模块保护。
• P1: 电压保护。
• P2: 压缩机顶部温度保护。
• P3: 室外温度过低保护。
• P4: 压缩机位置保护。

代码表：50FBPY、50BPY变频柜机

• E01: 一小时内变频模块连续保护四次。
• E03: 一小时内排气温度连续保护三次。
• P01: 室内板与室外板超过2分钟无法通讯。
• P02: IPM模块保护。
• P03: 系统电压过高或过低保护。
• P04: 室内温度传感器（房间温度）开路或短路。
• P05: 室外温度传感器（高温或低温）开路或短路。
• P06: 室内蒸发器温度异常（过高或过低），关闭压缩机。
• P07: 室外冷凝器温度过高，关闭压缩机。
• P09: 室外排气温度过高，关闭压缩机。
• P10: 压缩机顶部温度保护。
• P11: 系统正在化霜或处于防冷风运行状态。
• P12: 室内风机温度过热。
• P13: 室内板与开关板超过3分钟无法通讯。
• E0: 上电初始化时，读取EEPROM参数出错。

代码表：美的系列侧出风嵌入式空调器

• E1: 室内房间温度传感器T1开路或短路。
• E2: 室内蒸发器温度传感器T2开路或短路。
• E3: 冷凝器温度传感器T3开路或短路。
• Pd: 系统因电流异常触发四次保护。

代码表：Q1、Q2、Q3、U、V、J、V1、N、X、GA、H、A、B、K、W、FA、FB、FC、HA、HB、GC系列分体机

• E1: 上电时读取EEPROM参数出错。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E4: 系统电流异常，触发四次保护。
• E5: 室内房间温度传感器开路或短路。
• E6: 室内蒸发器温度传感器开路或短路。

代码表：P系列分体机

• E1: 上电时读取EEPROM参数出错。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E4: 四次电流保护。
• E5: 室内房间温度传感器开路或短路。
• E6: 室内蒸发器温度传感器开路或短路。
• E8: 过滤网复位出现故障。

代码表：Q系列

• E1: T1温度传感器故障。
• E2: T2温度传感器故障。
• E3: T3温度传感器故障。
• E4: T4温度传感器故障。
• E5: 网络通信故障。
• E6: 室外机存在保护性故障。
• E7: 加湿器组件故障。
• E8: 静电除尘功能故障。
• E9: EEPROM存储器读写错误。

代码表：S1、S2、S3、S6、Q1、Q2、Q3、U（U1）、P、K柜机、V、J、R柜、V2、W、GA、N系列

• E1: T1传感器故障。
• E2: T2传感器故障。
• E3: T3/T4传感器故障（泛指室外传感器）。
• E4: T4传感器故障（主要用于变频机型）。
• E5: 网络通信故障。
• E6: 室外机发生故障。
• E7: 加湿器故障。
• E8: 静电除尘故障。
• E9: 自动门运行故障。
• PAU: 进风格栅保护被触发。

代码表：5匹柜机系列新电控方案

• E1: T1传感器故障。
• E2: T2传感器故障。
• E3: T3/T4传感器故障。
• E4: T4传感器故障。
• E5: 室内机与室外机通信中断。
• E10: 压缩机运行压力过低。
• E13: 压缩机供电缺相。
• E14: 压缩机供电相序连接错误。

代码表：E2、E3、DC、DE、HA、F、I、G、GC、IA、IB系列柜机

• E1: T1传感器故障。
• E2: T2传感器故障。
• E3: T3传感器故障。
• E4: T4传感器故障。
• E5: 负载板与显示控制板通讯故障。
• E8: 室内外机通讯故障。
• E9: 开关门机构故障。
• EA: 压缩机低压故障。
• Eb: 室内直流风机失速。
• Ed: 压缩机缺相故障。
• EE: 压缩机相序反接故障。
• PAU: 进风格栅保护。

代码表：R型、S型交流变频系列、V型交流变频分体机系列

• E0: EEPROM参数错误指示。
• E1: 室内机和室外机通信故障。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E4: 温度保险丝断开保护。
• E5: 室外温度传感器故障。
• E6: 室内温度传感器故障。
• P0: 模块保护。
• P1: 电压过高或过低保护。
• P2: 压缩机顶部温度保护。

代码表：U型全直流变频、V型全直流变频分体机系列

• E0: EEPROM参数错误指示。
• E1: 室内机和室外机通信故障。
• E2: 过零检测出错。
• E3: 风机速度失控。
• E4: 温度保险丝断开保护。
• E5: 室外温度传感器故障。
• E6: 室内温度传感器故障。
• E7: 室外风机速度失控（V型全直流变频特有）。
• P0: 模块保护。
• P1: 电压过高或过低保护。
• P2: 压缩机顶部温度保护。
• P3: 室外温度过低保护（功能预留）。
• P4: 压缩机转子位置检测故障。

此前，我们从工程实践的角度对智能体（Agent）的发展脉络进行了一次概括性的梳理（详见：《万字：Agent概述》）。

时值2025年——这个被广泛称为“Agent元年”的最后一周，我们有必要以一种更为全面的视角，审视Agent技术在过去的这一年里究竟取得了哪些实质进展，各家公司的实际落地情况如何。所有这些观察与总结，都将为我们明确在2026年应该如何对待和布局Agent技术提供清晰的方向指引。

首先，让我们一同回顾2025年人工智能领域那些标志性的大事件。

模型能力构筑核心壁垒

本年度的开端便由两笔巨额融资奠定基调：

1. 软银（SoftBank）为履行对OpenAI总额225亿美元的资金承诺，在年底前紧急筹措资金，此时OpenAI的估值已攀升至约3000亿美元。
2. 以Claude模型闻名的Anthropic成功完成了130亿美元的融资，其估值也超过了1800亿美元。

与此同时，Meta公司也启动了一项规模浩大的人才争夺计划：

趋势非常明确：资本正以前所未有的规模涌入基础大模型领域，并且呈现出愈发显著的头部聚集效应。模型，作为未来AI时代的“操作系统”，正逐渐扮演起“赢家通吃”的核心角色。这意味着，顶尖的模型几乎可能渗透所有应用层。其他公司若想生存与发展，则需要围绕这些核心模型构建自身的生态。

AI编程：已验证的Agent成功范式

AI编程领域已成为当前最具确定性的现金流入口。其中，Cursor累计融资达32亿美元，估值接近300亿。Cognition / Devin、Replit、Lovable等公司也均有不俗的收获。

国内相关领域的发展相对滞后，虽有硅心科技、言创万物等参与者，但知名度有限。究其原因，在编程IDE（集成开发环境）这类核心生产力工具上，开发者群体普遍更信赖拥有强大技术背书的大厂产品。

事实上，市场上已涌现出一大批无需依赖风险投资的公司和产品，例如微软的GitHub Copilot、谷歌的Gemini Code Assist、阿里的通义灵码、Trae、CodeBuddy等。

AI编程之所以特别值得深入探讨，是因为它是目前少数能够真正令用户感到满意的Agent应用场景。该领域付费意愿强烈，验证链路清晰明确（能够运行测试、集成到CI/CD流程），并且直接替代的是成本高昂的人力资源。

AI编程能在众多Agent设想中脱颖而出，很大程度上得益于程序员群体对自身工作流（KnowHow）有着极为清晰的定义，同时GitHub等平台积累了海量高质量、结构化的代码语料。这种数据与认知的双重优势，是其他行业短期内难以复制的。

从AI编程的成功案例开始，我们可以窥见基于大模型的Agent大致分化为两种路径：

1. 通用型Agent，以Manus为代表；
2. 垂直领域Agent，以Cursor为典型。

就现阶段而言，通用型Agent的普遍用户反馈并不理想，但垂直领域Agent已经开始切实地解决特定场景下的实际问题。

垂直领域Agent备受市场青睐

除了AI编程，还有几款垂直Agent获得了业界的高度评价。首推Lovart，这是一款面向设计师的Agent。

它能够依据一句简单的提示词，直接生成一套完整的品牌级设计成果，包括主视觉（KV）、海报、多种尺寸的社交媒体图片等。用户无需搭建复杂的工作流程，上手即用且自由度极高，堪称当前最接近真实设计团队协作能力的AI产品。

另一款典范是OpenEvidence，一个专注于循证医学的“证据供给链Agent”。该产品旨在从根本上解决医疗场景中AI可能产生的“幻觉”问题。其核心功能是：紧密围绕医学文献与权威信息来源，生成有证据支持的回答并自动附上引用来源。

这些垂直Agent能取得成功，核心原因在于其所在领域的工作本身已经实现了高度的标准化流程（SOP）。对于Lovart而言，互联网上存在海量的图像及相关数据；对于OpenEvidence，医疗侧的临床指南、教材等信息数字化和标准化程度本身就非常高。

类似的产品还包括红杉资本青睐的法律AI——Harvey。它与Cursor、OpenEvidence一样，都获得了可观的融资。这揭示了一个重要趋势：资本市场并未盲目追捧所有标榜“Agent”的概念，而是有选择地押注于那些能解决真问题、具备清晰商业路径的垂直应用。

我认为，Agent技术正在从一个充满“泡沫”的故事概念，走向工程化、可交互的真实产品。一个简单的原因是：从纯工程实现角度看，一个基础的Agent框架技术壁垒并不高。因此，除了少数具备先发优势和生态的通用型Agent（如Manus）表现尚可外，其他通用方案普遍反响平平。与此同时，各大科技厂商也都在积极分食通用Agent平台这块蛋糕。

流量入口变革：从SEO到GEO

当前的流量分发逻辑已经发生了深刻变化。一个最明显的趋势是，企业不再愿意为传统的搜索引擎优化（SEO）支付过高费用。虽然AI应用获得的流量在增多，但围绕AI生成的、以答案为导向的流量获取（GEO）模式整体上仍不成熟。这导致许多公司虽有付费意愿却找不到有效渠道，该领域也因此成为“割韭菜”的重灾区。

本轮流量入口变革最直接的竞争体现是，各大公司都在竞相推出或强化自己的“AI浏览器”，包括Chrome（集成AI助手）、Dia、QQ浏览器、ChatGPT Atlas等。

其核心逻辑高度一致：用户获取信息的体验正从“搜索链接”转变为“直接提问获取答案”，各大巨头都在全力争夺这一新的核心入口。

企业数据资产成为竞争焦点

另一个竞争白热化的板块是AI办公自动化（AI OA）领域，这在国内主要对应两大即时通讯与协作平台：飞书与钉钉。对于大多数企业而言，引入AI的最大瓶颈往往不是模型能力不够强，而是企业内部不清楚有哪些流程可以且应该被自动化。

因此，这些平台的核心工作路径是：先帮助企业梳理和标准化工作流程（SOP），然后将其Agent化。有趣的是，飞书与钉钉在该领域的核心武器颇为相似：AI表格。它们本质上是在侵蚀传统Excel在企业数据处理中的市场份额。

在AI表格这类核心应用之下，还存在一些如Coze、Dify等定位“低代码/无代码AI应用搭建”的边缘角色。它们都希望分食AI OA这块蛋糕，但实际市场表现并不尽如人意。

尤其是Dify这类拖拽式低代码平台，其定位在一定程度上与强调代码生成的AI编程存在冲突。对于它们在2026年的整体发展方向，我持相对谨慎的态度。

可以预见的是，经过2025、2026两年的市场教育与实践洗礼，当各企业内部SOP梳理清晰、数据资产准备就绪后，真正的企业级Agent时代才会步入正轨。

在此需要特别提及钉钉最近的“木兰1.1”产品发布会。钉钉正试图提出一套标准化的范式，来系统性协助企业客户整理和激活自身的数据资产。

工程视角的观察与总结

从前述行业与市场情况来看，2025年确实可以被称作“Agent元年”，因为产业上下的一切动向都在为Agent技术的成熟铺平道路。

Agent的效能高度依赖于底层模型的基础能力。上文提到的几个成功Agent案例，其崛起也离不开大模型在编程、图像生成（尤其是“Nano Banana”这类技术）、医疗问答等特定领域本身就已展现出强大实力，而这些领域通常也是各类基准测试的重点。

这也引申出一种务实的开发策略：模型在哪个方面强，我们就做哪个方面的Agent；模型能力达到60分，我们通过工程和产品化将其体验提升到70分即可。

最后进行一下总结。从上述案例中，我们其实可以逐渐梳理出构建一个成功Agent的基本脉络：领域知识（KnowHow） → 高质量数据 → 标准化工作流（Workflow） → 可靠的Agent。

我的观点是：Workflow是通向实用Agent的必经之路。尤其是对于企业市场所需的Agent，其对稳定性的要求极高。然而，传统的Workflow系统维护到一定阶段后，复杂度会急剧攀升，维护起来异常痛苦：

为了解决Workflow维护困难、并提升其泛化能力，Agent架构应运而生。但早期Agent的表现往往不稳定，于是工程上尝试通过增加Token消耗、以“Token换架构”的方式来解决问题，不过实际执行下来效果并不理想。

随后，模型侧又提出了更多的工程优化策略，近期Claude推出的“Skill”策略可谓是集大成者。但问题也随之转移：之前是显式的代码化Workflow调用，现在则转移到了各个“Skill”的协调上，流程的复杂度被编码进了提示词中。简而言之：之前是用代码写Workflow，现在是用提示词写Workflow。

因此，MCP（Model Context Protocol）的提出是为了解决工具调用的工程问题，Skill的提出也是为了优化复杂任务处理。我们再来看看模型能力优化的演进图：

可以看出，模型能力的进化一直围绕着工具调用（Tool Use）进行优化。纵观整个2025年，模型在支持Agent方面的改进，我认为在“工具调用”相关问题上已经达到了及格线。接下来，模型很可能将啃另一块硬骨头：记忆系统。

现阶段，无论是RAG（检索增强生成）还是复杂的上下文工程设计，其构建难度和复杂度仍然过高。预计模型提供商将会推出类似Skill的、更工程化的记忆系统接口，大幅降低高效记忆系统的构建门槛。

近期，咨询AI训练营的学员颇为踊跃。然而，该课程存在一定的门槛，并不完全适合所有群体，例如缺乏工作实践和基础的在校大学生或非互联网行业从业者，学习起来可能会感到吃力。

尽管如此，许多同学依然希望把握当前的技术红利。为此，我们精心准备了一套简明的**《应用级AI学习路线图》**，旨在为这部分同学提供有效的指引。

需要注意的是，本路线图主要面向有志于从事AI应用开发的群体，例如AI工程师和AI产品经理。对于希望成为AI算法工程师的同学也有所裨益，因为实际情况往往是算法能力出色的工程师，未必能轻松解决工程落地问题。

在正式展开路线介绍之前，有必要先澄清一个普遍存在的困惑：普通人是否在AI时代失去了机会？

普通人真的无法分享AI红利吗？

许多读者曾被一张网络图片所传达的焦虑情绪影响：

“看了很焦虑，这图是不是太夸张了？难道做AI和做光刻机一样，只需要极少数顶尖人才？”

经过分析，我认为这种焦虑很大程度上是自我施加的压力。原图并未断言AI领域只需极少数人，其核心观点在于：平庸所承受的代价从未如此高昂，而卓越所获得的回报也从未如此丰厚。文中随后引用了一些国外实例：

据《财经》不完全统计，Meta曾以天价从OpenAI挖角，为部分顶尖AI科学家开出了为期四年、总额高达2亿至3亿美元的合同。

文章也提及了国内AI岗位的薪资状况：硕士应届毕业生月薪5万在AI行业被称为‘底层’？这令我有些惊讶，但在AI领域，这确实是一个相对较低的数值。

读者焦虑的焦点在于 “应届生都能拿到5万月薪！”。然而，我们不应只关注金字塔尖的数字。年薪百万的应届生实属凤毛麟角。基于以往的招聘经验，即便是清华大学、北京大学的毕业生，多数人的年薪范围也在40万至60万元。

诚然，近两年AI算法工程师的待遇确实非常优厚（不乏年薪破百万者），但这里需要给大家提供一个客观的视角：算法工程师这班快车，对于大多数人而言可能真的难以搭乘。

因为这个方向技术壁垒极高且竞争异常激烈。国内仅有少数几家大厂在进行底层模型的研发，即使是985高校的硕士毕业生，在其中也可能面临巨大挑战。对于普通背景的学习者来说，这几乎是难以逾越的鸿沟。

因此，建议大家不必将大量精力投入学习高等数学、线性代数、概率论、机器学习理论等底层原理。

方向选择错误，再多的努力也可能徒劳无功。一个目标是工程应用的人才，若执着于啃食底层理论，很可能事倍功半。

那么，普通人在AI时代的机遇究竟在哪里？答案清晰地指向了应用层。

真正的机会在于应用层

尽管难以分享基座模型研发的红利，但无需过度担忧，因为AI应用层所带来的市场机遇才是真正的蓝海。根据红杉资本AI峰会的保守预测：AI应用的市场规模将达到万亿美元级别！

为了帮助大家更全面地理解AI应用，此处以一个亿元级别AI项目的完整工作分层/分级为例进行说明：

1. 模型全训练：包含预训练、微调、强化学习等环节，目标是不依赖外部大模型，实现完全自给自足。通常只有极少数公司会涉足（成本极高），此处仅为保持框架完整性而列出。
2. 整体架构设计：涵盖AI工程、数据工程，重点是AI与数据的协同。在此阶段需确定基础的知识库结构与工程架构，这是公司知识产权与核心壁垒所在。
3. 模型调优：涉及后训练、RAG（检索增强生成）等技术的深度应用，往往是项目的核心策略，属于架构之下的工具技术层操作，也是面试问题的高发区。
4. 提示词工程：细化到各个业务模块的标准作业程序编写，是公司业务逻辑的具体化展现。
5. 数据工程具体作业：针对特定板块的详细数据验收。通常在基础架构验证完成后，需要协同各专业人员收集AI工程所需数据，这是公司数据壁垒构建的关键。
6. 模型测评：涉及行业AI应用评测标准的执行（方案设计属于整体架构，此处是具体执行），包括测试数据集准备、竞品调研、非标数据收集等。
7. 论文与公关相关：主要为学术成果发布与市场宣传，一般人员较少涉及。
8. 简单工具选型：包括常用工具的调研与选择，例如向量数据库、Agent平台（Coze, Dify, n8n, LangChain等）。
9. 降本增效工具开发：例如数据知识库后台、提示词管理后台（当提示词数量达到数十万级别时需要）。此类工作技术含金量可能不高，但权限控制至关重要，否则易导致公司机密泄露。
10. 实施团队：对于开发To B AI工具的团队，可能设有实施团队，负责工具售前或实际行业落地，属于项目执行层。
11. 其他辅助性工作，如资料准备、数据确认等。

虽然多数公司的AI项目投入达不到亿元级别，但其具体工作内容必然是上述模块的子集。这里的每一个模块，都是潜在的技术切入方向，并且越是靠后的模块，入门难度相对越低。

另一方面，AI项目的技术路径有时颇具“禅意”或“谜语”特质——未曾点破时百思不解，一旦道破则豁然开朗。因此，通常只有公司最核心的少数成员能够窥见项目全貌，且职位越高，接触的信息越全面。

故此，在设计个人学习路径时，务必坚持自下而上的原则。脱离了实践的学习，无异于纸上谈兵。

接下来，将为大家呈现具体的学习路径与资料推荐。

对于AI产品经理和AI工程师，学习路径大体一致。区别在于，AI工程师需要具备一定的编程基础，建议额外学习一门语言，例如阅读**《Python编程：从入门到实践》**。之后的路径便可统一进行。

第一阶段：掌握Agent平台

首先，Agent平台是必须掌握的技能。因为超过80%的企业在初步尝试AI时，第一件事就是在Coze或Dify上通过拖拽方式搭建工作流。尽管他们后期可能会发现其局限性，但作为学习者，我们不应逆主流趋势而行。

况且，这些平台确实具有实用价值。以长期实践经验来看，Coze堪称AI产品经理的利器，有了它，制作演示原型基本无需依赖程序员，极大地拓展了能力边界。

常见的Agent平台包括Coze、Dify、FastGPT、n8n等。其中，必须熟练掌握的是Coze和Dify。选择Coze是因为其门槛极低；而Dify则是私有化部署的主流选择。

• 开源版Coze 和 Dify 深度 PK：谁能成为你的 AI 应用开发利器？
• Dify内心：Coze开源只是太监版本，我一点都不慌！

学习的深入标准是：能够进行技术选型，即清晰阐述在不同场景下应选择哪个平台及其原因。这意味着需要建立一套统一的评价体系来评估各类Agent平台，例如考量以下维度：

明确了学习目标后，实践方法反而变得简单：尝试实现一个通俗易懂的工作流即可，例如一个简化的HR招聘工作流：

当你能够熟练运用Coze后，便可以进入下一个主题：AI表格。

第二阶段：精通AI表格

当一家公司开始使用Coze后，他们几乎必然会接触到AI表格（或称多维表格）。而大多数公司最终会发现，AI表格才是其中后台业务AI应用落地的关键。原因在于：

• AI企业落地真相：90%靠工程，10%才是模型？当然不是，分类都是错的…
• “90%工程、10%模型”是真相吗？一个AI表格案例给你答案

各个公司的中后台部门天然亲近Excel类产品，而AI表格完美解决了Excel在多人协作中的核心难题。

以近期某钉钉产品发布会为例，上午简短开场后，接连展示了钉钉生态下的三个典型赋能案例：

1. 第一个是直播电商赋能；
2. 第二个是工业制造赋能；
3. 第三个是全球化的应用。

值得注意的是，这三个案例本质上都是AI表格的应用。而下午场的核心内容依然聚焦于AI表格！此外，飞书体系的多维表格也在持续发力。