从去年开始，整个AI世界愈发呈现出“乱花渐欲迷人眼”的景象：

1. 前一日刚推出Manus，次日便冒出一个Lovart；
2. Cursor的热度尚未消散，Claude Code 就已经成为AI编程领域事实上的领先者；
3. 刚还在讨论提示词怎么写，资深的从业者就断言RAG已经过时，随之抛出“上下文工程”的概念；
4. 正当我们为Coze的开源而惊叹时，Google Nano Banana已经刷遍了朋友圈；
5. 飞书发布会还在浓墨重彩地介绍多维表格，钉钉便迅速跟进，强势推出AI表格；
6. 医疗AI领域的OpenEvidence估值高达120亿美元，法律AI Harvey的估值据说也接近110亿。

随后，OpenClaw骤然走红，迅速掀起了一场“百虾大战”：

而结果大家都已了然——OpenClaw 并没有活跃太久便逐渐式微，与此同时，Hermes 又接踵而至。

正是在这种情形下，我反而生出一丝庆幸：在AI时代，如果学得足够慢，似乎也就真的不用急着去学了……

与此同时，互联网公司的裁员消息此起彼伏，一则颇为夸张的传闻称某小破站裁员比例高达60%！

出于对就业市场整体情绪的关切，我在几个社群中对产研人员进行了调研，结果令人感慨：超过一半的人认为，到2026年很可能会有半数程序员面临失业，接近三分之一的人认为这一概率“有一定可能”。

此后，OPC风向渐起，若换作你我是普通打工人，又如何能不为未来焦虑？

那么，老板们的处境就轻松吗？

看不懂的老板

他们当然同样焦虑。仅就我在年后接触的众多老板来看，其焦虑程度甚至更为深重，而原因也十分直接——他们确实难以看懂。

比较典型的一个案例是：西安一位企业主带着整个管理团队专程赶来成都，只为当面与我交流一回……

他们所从事的是传统工业信息化领域，偏重ERP模块，公司已经稳定运营了15年。

按照老板本人的说法，在过去，他们一直顺风顺水，一切都在既定轨道上推进。可AI一出场，就将他们彻底打懵了。如今不单是他们感到困惑，就连金蝶、用友这类大厂也同样满头雾水，而那些大企业调整航向则更加迟缓。

据该公司的技术负责人讲述，老板几乎焦虑得夜不能寐，天天追问接下来该如何转型，还经常在深夜往群里转发大量关于AI的信息。

我完全能理解他们的焦虑，只不过接下来的场面就有些令人意外了：在简要介绍了自家业务之后，他们竟然直接向我发问，问我他们接下来应当制定怎样的AI战略。然而，这个问题我又怎能轻易回答？

一方面，这里存在信息量的巨大不足；另一方面，这当然还有价值对等的问题……

混乱是因为角度问题

无论是上述的打工者还是老板，他们都深陷焦虑。在AI时代，焦虑几乎成为一种常态，其背后隐藏着许多耐人寻味的故事。比如，最近频繁出现的“蒸馏.skill”就是其中之一：

我无从知晓是哪位极具创意的同行最先提出了蒸馏一词，并将其定义为skill来实现，我猜测最初可能只是无心之举，然而后继的发展却十分夸张：

1. 还真有老板跑来跟我说，想把某人的能力“蒸馏”一下；
2. 也确实有员工因此而担心自己会被“蒸馏”掉。

天哪，真是“内行看门道，外行看热闹”。如果你真正使用过skill，或者真正尝试去做一次所谓的蒸馏，你就会明白这件事有多么不靠谱。问题倒不在于完全不可行，而是意义极为有限。类似的事情在两年前，我们早就利用Coze实践过了。我印象中，那时流行的是奥德彪式艺术表达：

看似很危险，实则一点也不安全
年轻时很穷，干了几年终于不年轻啦
趁年轻你的多吃苦 老了你就习惯了
虽然路途遥远， 但你别担心，也挣不到什么钱
是金子总会发光，但大家都是老铁
爱情不是生活的全部 打工才是
……

所有这些语句读起来很痛快，但终究只是形式上的相似。我举一个最简单的例子来说明：

1. 试着蒸馏出一个协和医院顶级专家的skill；
2. 再蒸馏出一个“法外狂徒张三”的skill；

如此生成的“东西”所提供的医疗建议或法律意见，你敢采纳吗？

所谓蒸馏、skill，似乎并没有多少人真正把OpenEvidence与Harvey的估值当回事……

写到这里，或许有人会感到疑惑：开头还在讨论焦虑，为何现在又开始吐槽起来了？

实不相瞒，因为我实在演不下去了——其实我几乎一点也不焦虑，之前的焦虑，不过是刻意表演出来罢了……

相应地，我也绝非单纯为了吐槽。之所以这样说，是想告诉大家：其实，你们也大可不必如此焦虑。接下来，我将带你用一种工程视角去观察AI的发展，或许你的心态就会从容得多：

宏观视角看AI

AI发展至今已经三年多，我们首先要问的是：如何从宏观上总体把握这三年的AI演进？

大家可以先回想一下，在你脑海中，那些标志性事件都有哪些？

请回顾那些真正有影响力的AI事件、那些为你的工作与生活带来改变的AI产品，或者那些对就业市场产生巨大冲击的AI时刻，先后又有哪些？

我们梳理这些事件，为的是将AI世界划分为不同的阶段，这是一种分类思维，分类一旦清晰，看待问题便会愈加透彻。

一个相当经典的分类法，是OpenAI的Sam Altman所提出的L1至L5分级，确实能够说明一些问题：

我们可以对照这张图大致勾勒时间线：

2022年底，ChatGPT 3.5 的发布，标志着我们正式跨入以大模型为核心的AI时代。

整个2023年，堪称百模大战时期，国内标志性的事件是文心、智谱等模型的相继面世，然而都未能激起太大波澜。2023年是国内的AI 1.0阶段，各家训练类公司最终留下的，更多是一地鸡毛。

进入2024年，我们常说的AI 2.0时代到来，那是一个以RAG为主导的阶段。当时的情况相当微妙：经历过百模大战的消耗，许多公司账上已近枯竭，对“训练”二字深恶痛绝。

Anthropic 将筹码押在终端，Cursor 死守 IDE，OpenAI 则开辟云端异步代理——三条截然不同的技术路线，对应三款工具对未来编程形态的完全对立的设想。本文从底层架构到六类真实开发场景，逐一拆解它们的能力边界，同时涵盖成本对比、组合策略与下半年趋势判断，帮助你摆脱“该选哪个”的焦虑，找到最高效的工具搭配方式。

AI 编程工具的选择困难，正在成为开发者绕不开的新痛点。面对 Claude Code、Cursor、Codex 这三款话题度最高的帮手，很多人下意识会问：哪一个最好用？但这个问题本身就有误区——因为它们根本不是同一类产品，无法用一把尺子丈量。Anthropic 相信命令行才是未来，Cursor 赌开发者离不开 IDE，OpenAI 则直接把编程变成了后台异步任务。三家公司对“AI 该如何参与编码”给出了完全不同的答案，也就意味着不存在通吃的赢家，只有和手头场景贴合度最高的那一个。

💡 本文核心主张： 不存在“最好的工具”，只有“最适合当下任务的工具”。吃透它们各自的设计哲学和适用边界，才可能做出真正落地的选型。

一、先看清设计理念：三种路线的底层假设

选工具的第一步不是罗列功能，而是读懂它背后藏着什么假设。功能只是皮肤，真正划定能力疆域的是它对“AI 编程应该以什么形态存在”这一问题的回答。

🏗️ AI 编程工具的三种技术路线

Claude Code：终端就是整个工作室

Anthropic 的判断非常激进：未来的开发者根本不需要图形界面，命令行足矣。Claude Code 被设计成一个纯粹的 CLI 工具，不与任何特定编辑器绑定，它在终端里直接读写文件、执行 shell、运行测试、操作 git。这份“原始感”带来了几个其他工具很难复制的优势：

• 无边界工具链整合：
  通过 MCP（Model Context Protocol）可以对接 GitLab、Jira、数据库、日志平台，不受 IDE 生态的约束，几乎任何系统都能接入。
• Hooks 驱动的自动化流水线：
  在代码生成前后自动触发 lint、format、测试，把质量把关变成后台默认行为。
• 子代理并行推进：
  能将复杂任务拆解给多个 Agent 同时执行，大幅缩短整体耗时。

当前版本 v2.1.x 配合 Opus 4.6 模型，具备 200K token 上下文窗口。学习门槛的确不低，需要习惯终端工作流、学会精准编写 prompt、理解 MCP 配置。但一旦跨过这道坎，处理复杂工程任务的效率会有肉眼可见的提升。

从终端敲下指令到 Agent 吐出最后一个字，背后走过了很长一段链路：

1. 消息先被入口收拢，转换成内部统一的消息对象；
2. 会话和上下文被重新组织；
3. 模型开始多轮推理，必要时调用工具；
4. 过程过长时，系统还要整理上下文、保留历史记录，并在任务结束后尝试沉淀经验。

走过这条链路，Hermes‑Agent 的骨架大致浮现出来。但这种方式更像一次源码漫步，遇到什么模块就解释它在消息路径上的职责，撞见某个工程细节就顺手拆解为什么这么做。

问题也恰在于此：跟着流程走容易熟悉框架，却很难真正理解那些散布各处的设计抉择。例如：

1. Profile 为什么依赖 HERMES_HOME 做隔离？
2. 系统提示词为什么越稳定的越要靠前放置？
3. 记忆为何要在会话开始时冻结成快照？
4. 上下文压缩后为什么不覆盖旧会话，而是用父子链新开一个会话？

这些细节单独拆开来看都不算大，甚至只是很小的工程取舍。可一旦放在一起，它们共同指向了一个问题：

Agent 要真正进入工作流，需要的是一套围绕模型构建的工程约束。

上一篇我们沿着消息看见了模块如何运转。这一篇换一个视角：这些模块组合在一起，究竟构成了什么？为什么这些看似零散的设计，最终会汇聚到同一个系统层——Harness。

更进一步：未来的软件是否也要开始为 Agent 做设计和改造？

Harness 是什么

在软件工程里，test harness 是一个成熟的概念：它是指围绕被测代码搭建的基础设施，负责提供输入、捕获输出、管理执行环境，让测试变得可重复、可自动化。被测代码本身不必修改，harness 从外部包裹它，替它处理所有外部依赖和环境问题。

大模型的本质只是一段文字输入，经过推理后输出一段文字。但它不会自己调工具，也不会替你管理上下文、处理错误、记住上一次做过什么。这些能力需要外面有一层系统来补全。

现在我们把这层系统称为 Harness。我更愿意把它看成 Agent 的运行时：模型提供能力，而任务如何推进、工具如何调用、状态如何保存，都交给这层系统。模型是能力源，Harness 决定这股能力能不能从演示走向真实。

几乎所有 Agent 项目的起步阶段都差不多：接入一个模型，写一段系统提示词，挂几个工具函数，再搭一个聊天入口。这个阶段很容易见到效果，尤其针对简单任务、少量工具、模型规模足够时，表现往往相当不错。

但用户的意图没有边界，不会只扔一个孤立问题。今天让 Agent 查资料，明天让它接着昨天的结论修改方案，后天又补充一条新限制。任务执行到一半，会发现文件权限不足、需要确认；运行测试时环境不对；工具返回的错误难以理解。再加上上下文越拉越长、工具列表越来越多，原先“模型加函数”的结构很快就会撑不住。

此时难点已从“会不会调用工具”转换成“能不能在一套可控系统里做事”。如果不在系统层面处理这些问题，就只能把它们塞进 prompt。一开始可能有效，任务一长，这些说明书式的指令很快就会被模型遗忘。这些判断不能全凭模型去猜，必须在模型外面有一层系统把这些事管起来。

起初它们像一堆零散的工程补丁，放在一起看，就是 Harness 的雏形。下面我们沿着 Hermes‑Agent 里几个最典型的设计往下走，每个点都不大，但放到一起，会看到一个 Agent 从聊天壳朝着运行时系统生长的过程。

LLM 与系统

上一篇从一条消息开始。用户输入一句话，表面只是请 LLM 帮忙做事，但系统内部早已发生了多层转换。入口层先把不同来源的消息统一起来：命令行、Telegram、Slack、飞书、Email，这些入口的交互方式截然不同，进入核心后都会被收敛成一套内部的消息对象。

往外走时亦然：模型不需要知道飞书怎么传附件、Discord 怎么带文件，它只需吐出统一的媒体协议，再由网关转换回各自平台的格式。这一步是把平台差异挡在 Agent 核心之外。

再往下是 AI Agent 的主循环：它先决定调用什么工具，系统去执行，然后把结果拿回来，它再根据结果判断下一步，如此反复，直到给出最终回答，或者预算耗尽，又或者用户主动打断。

Agent 做事不会一帆风顺，中间会报错，也需要模型根据工具的执行结果不断思考、重试。一个真正能工作的 Agent，必须允许这种来回调整，否则就只能处理短任务。任务一旦复杂，要么执行不下去，要么直接返回一个看似合理的假结果。

2026 年开年以来，AI 领域迎来两波巨大福利：

第一是 OpenClaw 的爆发，并非因为它直接解决了多少深层问题，而是它首先为 Agent 的普及做出了空前贡献；同时，OpenClaw 基本奠定了由 Agent 驱动 Skills 的基础交付范式。

第二是 Claude Code 源码的泄露，这为许多正在 Agent 赛道上创业的团队提供了大量高质量范本。在 CC 之前，大家对“Harness 驾驭工程”的理解仍是模糊的。

不过，前景虽好，现实依然存在不少问题。根据我的观察与实践：目前 Agent 技术远未成熟，OpenClaw 在执行任务的稳定性与安全性上仍有巨大的提升空间。

因此，后续必然会有越来越多的 Agent 涌现，每次迭代都能前进一小步，比如最近逆势而上的“Hermes”：

Hermes Agent 从 2 月底开源首月即破 2.2 万星，至 4 月 8 日发布 v0.8.0 版本后，单日新增 6400+ 星，不到两个月 GitHub 总星标突破 4.7 万，多日占据全球开源榜首。

OpenClaw VS Hermes

近来常听到“OpenClaw 已死，Hermes 称王”“Hermes 碾压 OpenClaw”之类的言论，说实话，听得有些烦，虽然我自己偶尔也会使用类似标题……

这个 Hermes 到底是个什么东西，又凭什么能与 OpenClaw 一较高下？我们这里还是要回归本质，尽量从工程角度（少量源码切入），为大家展开论述。

首先，OpenClaw 是一个用 TypeScript 编写的 AI 助手平台，工程化程度相当高。我之前写过几篇拆解文章，在本篇开头有链接，可以回顾查看。

Hermes Agent 则由 Nous Research 团队开发，使用 Python 编写，是一套可开源商用的 Agent 平台：

Harness 最近吸引了越来越多的关注，但它与 OpenClaw、Hermes 并不完全同类——它还未落地成具体的产品，至今仍停留在框架性定位：为 Agent 的稳定执行而生。

目前平台上关于它的内容，要么过于抽象，要么又失之琐碎。

若想真正理解 Harness，不能只看概念，最好将它与当下运行优秀的 Agent 框架（如 Claude Code、OpenClaw、Hermes）结合起来，才能将其拉回到工程现场审视。

Harness 诞生背景

伴随着 Agent 技术的演进，尤其是 OpenClaw、Hermes 的发布以及 Claude Code 源码的亮相，全球对 Agent 开发范式的认知被推到了新的层次。

在此背景下，Harness 一词的走红并不突兀——当 Agent 真正开始承担任务，工程上的矛盾再也遮掩不住。

正如业界常说的：

Demo 展示的是范式方向，而工程实践才能真正定义范式是什么。

Martin Fowler 在 2026 年 4 月的文章中，将 Harness Engineering 定义为围绕编码类 Agent 建立的信任体系，其核心是通过上下文、约束条件、反馈回路和工程结构，让人一步步敢于把任务交托给 Agent。

Anthropic 官方工程文章同样把 Claude Code 视为一种优秀的 harness，并深入讨论了长时运行 Agent 以及长时应用开发场景中的 harness 设计。

补充一点：Claude 总爱强调自身优势不仅在于模型，也在于工程；但在我们使用国内框架并接入 Claude 模型后，能力提升同样显著。因此我认为 Claude 真正的强项是 Coding，而国内工程水平未必落后。

基于这些，我们如今探讨工程范式的集大成者 Harness，自然不能继续在提示词工程的圈子里打转，上下文工程似乎也不足以覆盖其全部含义。问题已经回归到了本质：

为什么 OpenAI、Hermes、Claude Code 等 Agent 框架，在演进过程中都会发展出一整套工程系统？
而这套系统，为什么越来越像决定 Agent 成败的关键？

五层架构

从终端敲下一句话到最后一个字回到屏幕上，中间发生的所有事情，就是一个 Agent 的完整骨架：跟着一条消息从头走到尾，就能拉出它背后的整条链路。

消息接收、平台适配、会话管理、上下文组装、记忆注入、技能发现、流式执行、工具调用、上下文压缩、子 Agent 分发、错误恢复与凭证轮换、状态持久化

在终端执行 hermes 启动新会话，输入：

帮我搜集今天的热点新闻  
每条新闻要分类(科技、财经、社会、国际等)  
并附上简要分析和总结

这背后包含：搜索热点、分类判断、简要分析、格式化输出。过程涉及多轮工具调用（web_search 搜新闻、web_extract 提取详情）、信息整合、分类归纳。如果来源和数据量都大，还可能需要拆分子任务并行搜集。

Hermes Agent 是怎样把这些事串起来的？先从整体架构讲起。

• 入口层：CLI + 二十多个消息平台适配器（飞书、钉钉、Telegram、Discord、Slack、WhatsApp、iMessage、Email、SMS……）
• 网关层：GatewayRunner 常驻进程，管理连接、会话生命周期、斜杠命令
• 执行层：AIAgent（run_agent.py），组装上下文、调模型、跑工具、处理错误，是整个项目的心脏
• 扩展层：工具注册中心、技能系统、子 Agent 委托、MCP 客户端、8 个外部记忆 Provider
• 存储层：SQLite + FTS5、MEMORY.md / USER.md、Skills 目录、config.yaml、.env

一条消息的完整路径：

终端输入 → CLI 解析 → 会话加载 → 上下文组装 → 模型推理 → 工具执行 → 流式输出 → 状态落盘

接下来逐层拆解。

一、适配器模式的内外统一

终端是最直接的入口，但 Hermes 支持 20+ 平台，每个平台消息格式都不同：Telegram 长轮询、Slack WebSocket、Email IMAP、SMS HTTP Webhook。

Hermes 为每个平台写了一个适配器，全部继承自 BasePlatformAdapter。

最近体验了钉钉悟空，上手后最直观的感受是：它非常适合内容创作者。和以往在办公软件中“塞”几个AI功能不同，悟空从底层就完全按照 Agent 的思路来设计。而在之前，我一直在使用飞书 Aily，也是一款 Agent 产品。深度使用后，最大的感触是，这两款产品走的是完全不同的路线。

悟空下载地址：https://wukong.dingtalk.com/

下面通过几个实测案例来详细说明。

小红书内容自动化

如果你在寻找更智能的小红书运营自动化方案，这个例子会很值得参考。

以往通过影刀等工具实现小红书自动发布，主要依赖模拟点击操作。现在悟空在 Agent 层面就能完成这类任务，并且配合信息收集能力，能够形成从搜集到输出的一体化闭环。

我试着让它收集小红书上近期热度较高的护肤品产品。

悟空会自行启动内置浏览器，前往小红书 APP 进行搜索，之后把搜索到的数据整理并汇总进钉钉表格。

把同样的需求交给飞书 Aily，会发现它无法调用本地浏览器登录小红书搜索信息。它只能在不同信息平台检索，比如新闻网站、头条等。

差距非常明显：悟空可以基于小红书上不同产品的热度进行信息采集，而飞书 Aily 则不行。虽然飞书 Aily 也能打开 AI 浏览器，

但经常卡在登录界面。当然，飞书其实可以通过接入 OpenClaw 来完成这个流程。这正是两者本质上的区别：一个是附加了 Agent 功能，另一个则自带 Agent 能力。

接着，我让悟空帮我发布一篇小红书笔记。它会打开小红书，按照指令操作相应界面，自动填充内容并完成发送。

定制化的信息收集流程

作为 AI 领域的博主，每天都需要搜集信息制作内容。于是我给悟空配置了一个 AI 新闻定时任务。

经过几次需求确认后，悟空开始创建定时任务。这里它并不是直接调用网络搜索，而是打开本地浏览器获取信息。

这就是悟空 CLI 能力的优势。因为信息是从网页上直接获取的，我也可以在网页上进一步操作。比如，我想获取“量子位”热门板块里的“热门文章”信息，就可以在定时任务中单独说明。

而且，收集到的信息还可以保存到本地电脑，用于后续其他用途。

高质量视频内容生成

悟空不仅内置了常用功能，技能市场也非常丰富。

我使用了“动画大师”技能，制作一个关于人口数量变化的动态视频。

下面是生成的视频效果。

已关注

Follow

Replay Share Like

Close

观看更多

更多

退出全屏

切换到竖屏全屏**退出全屏

叶小钗已关注

Share Video

普通人如何构建AI项目认知框架：从焦虑到体系的系统学习路径

本文希望探讨一个很现实的问题：在 AI 热潮越来越猛的当下，普通人究竟该怎样进入 AI 行业？

如果你最近也在为此焦虑、内耗，对学什么、怎么开始感到迷茫，这篇文章应该会为你提供一个清晰的思路。

如今焦虑的人越来越多，尤其是企业管理者与程序员。对他们而言，AI 的发展速度已经快到让人难以判断自己当前所做之事一年后是否还有意义，焦虑带来的失眠与节奏混乱也随之而来。

从去年开始，整个 AI 世界可以用“乱花渐欲迷人眼”来形容：

1. 今天发布了一个 Manus，明天就会冒出一个 Lovart；
2. Cursor 还没被大家真正捂热，Claude Code 就已经成了 AI 编程领域事实上的新王者；
3. 上一秒还在讨论提示词怎么写，下一秒行业前辈就说 RAG 已经过时，并顺势抛出“上下文工程”；
4. 正感叹 Coze 竟然开源了，Google Nano Banana 又立刻刷爆了朋友圈；
5. 飞书发布会刚浓墨重彩地介绍完多维表格，钉钉马上跟进，强势推出 AI 表格；
6. OpenEvidence、Harvey 这类垂直 AI 项目的估值越来越高；
7. 紧接着 OpenClaw 爆火，掀起百虾大战，结果没多久 Hermes 又来了……

如果你只是一味地追逐这些热点，的确很容易陷入慌乱，因为你会产生一种错觉：

AI 世界的底层逻辑，似乎每天都在被彻底重写。

但坦诚地讲，很多人的焦虑并不是因为 AI 真有那么可怕，而是因为他们没有建立起自己的判断框架。

没有框架，就只会被热点推着走：

1. 今天追 Manus，明天追 OpenClaw，后天再追 Hermes；
2. 今天学 Coze，明天学 Dify，后天又觉得是不是该 all in AI Coding。

折腾了一大圈，时间花出去了，脑子里的知识却仍然是碎片。于是，问题也就随之而来：

一个普通人如果真的想进入 AI 行业，到底应该怎么学？

什么该学，什么不该学？

什么方向更现实，什么方向只是徒有其表的热闹？

先说结论：普通人进入 AI 行业，主要的机会并不在算法岗，而在业务落地。

前面我们讨论过，LangChain 与 LangGraph 仍然是开发者社区最推崇的 Agent 框架，尤其在复杂业务场景下，他们为开发者铺好了一条从组件封装到流程编排的工具链：

随着 LangChain 1.x 和 LangGraph 1.x 版本逐步成熟，这套体系的职责分工与工程化落地也愈发清晰。我们团队长期从事 AI to B 业务，既做过 Demo，也交付过正式项目。但在实际业务中摸爬滚打后，我渐渐告别了 LangChain，转而选择贴近业务本身的开发模式。

这绝不是说 LangChain 不好，能成为行业标配必然有其不可替代的价值。只是技术选型从来不是追着热点跑，关键要看它是否真的与你的项目阶段相匹配。

框架的意义，最终还是要落到项目规模、业务需求和技术栈的匹配度上

今天，我结合自身踩过的坑，聊聊放弃 LangChain 的几点理由，以及在做 AI 应用开发时，框架取舍的一些核心原则：

1. **小项目/原型验证：**直接使用原生 API 开发，灵活零依赖，试错成本极低。
2. **中型/进度紧张项目：**借助 LangChain 快速搭建骨架，但必须提前规划技术债的偿还路径。
3. **大型/企业级项目：**强烈建议自研框架，实现与微服务架构、现有基建的深度整合。

核心观点： AI 编程时代，手写“胶水代码”的成本趋近于零，自研框架的门槛已大幅降低。

一、我们真的需要AI开发框架吗？

在判断该不该用 AI 框架之前，不妨先厘清：AI框架到底是什么？

AI框架的实质，是给开发者提供一套标准化的解决路径，把那些反复出现的造轮子动作打包起来，提升开发效率，并让团队协作保持一致的节奏。

在开发 AI 应用时，大量工作是共通的：比如大语言模型的调用封装、Prompt 模板管理、向量数据库对接、各类工具链的接入（搜索、计算、数据库操作），还有对话历史的维护等等。这些能力在不同项目中往往是相似的，天然具备抽取出来形成底层框架的条件。这也是框架最核心的价值：

1. **提效：**即便不熟悉底层细节的开发者，也能用少量代码快速实现复杂功能，绕开常见的坑。
2. **标准化：**团队成员遵循同一套开发范式，沟通和集成成本显著下降。
3. **生态成熟：**框架一般会内置主流工具（如 OpenAI、Pinecone、Chroma）的适配器，省去自己一个个对接第三方接口的麻烦。

但另一方面，框架也并非万能解药，它的局限性同样明显：

1. **灵活性不足：**为了适配各种场景，框架往往会堆积大量抽象层和依赖，这不仅加重了项目复杂度，还可能带来性能上的额外开销。
2. **预设逻辑的束缚：**当业务需要个性化调整时，框架内置的逻辑常常变成桎梏，改动起来比重写还痛苦。
3. **学习曲线：**表面上看入门门槛降低了，但真正要用好它、排查问题，还得吃透其内部机制。否则很容易陷入“只会调 API，不知道底层原理，出了状况无从下手”的困境。

所以，用不用框架，本质是在开发效率与灵活可控之间寻找平衡。而找到这个平衡点的关键，就在于认清你的项目规模与需求特征。

就实践来看：多数团队其实并不具备长期维护框架的能力，这意味着一遇到版本升级或者碰到付费模块，就会非常吃力，甚至有推倒重来的风险。

下面我们按不同项目类型，逐一展开来看。

二、小项目：原生开发才是真香

对于小项目、Demo 验证，或是内部工具开发，我的态度一直很明确：优先选择原生开发，不引入任何重型框架。

这类场景的核心追求是快速把想法落地或者跑通业务流程，比如搭建一个简单的对话机器人、做一版 PDF 问答工具、生成文案助手等。功能本身比较单一，边界清晰，根本用不上复杂的架构。此时引入 LangChain，只会平添一层不必要的复杂度，反倒是 Coze、Dify 这类轻量平台更加顺手。

最近几个月，身边越来越多朋友开始用AI辅助写代码，甚至有人搞起了“养小龙虾”的副业。大家聊Agent时，话题往往不是它能帮我们做什么，而是——“今天又烧了多少钱”。贵，是大家最大的痛点。

尤其是像 OpenClaw 这类Agent工具，执行任务时不断规划、反思、调用工具，单次对话携带的上下文极其庞大，Token消耗往往是普通聊天的数倍甚至百倍。

国产大模型这两年的进步有目共睹：GLM、DeepSeek、Kimi、MiniMax、Qwen等旗舰模型层出不穷。但想每家都试试真实效果，就得一次次去注册、换Key、改接口，折腾一圈头都大了。

直到讯飞星辰上线了「Astron Coding Plan」，把这些模型打包成一个订阅套餐，按月付费，不再按Token算钱。

作为打工人，最关心的当然是性价比。打开套餐页面一看，真的惊了——竟然有 3.9元/月的套餐。

说真的，现在3.9元连一顿早餐都拿不下来。

我毫不犹豫就订阅了。

订阅地址：
https://maas.xfyun.cn/modelSquare?ch=MaaS-jg-kol-X3c8

固定月费，不再按Token计费。
套餐按请求次数结算：

• 无忧版：请求次数不限，有模型限制，一般任务完全够用。
• 专业版：每5小时1200次，每月约18,000次请求。
• 高效版：每5小时6000次，每月约90,000次请求。

用过Agent的朋友都知道，处理复杂任务时，反复推理、多轮工具调用，心里总要盘算这次又花了多少，还常忍不住敲 /cost 看一眼。Agent的Token消耗大约是普通聊天的100到1000倍，纯按Token付费，真的扛不住。

讯飞这个套餐，把计费单位从Token换成了调用次数，看似只是计价方式变了，实则让使用逻辑更清晰：你不再为那些看不见的海量Token焦虑，只需关注完成了多少次调用。对Agent这种“话痨”场景，简直太友好。

一个模型名，随时切换多款旗舰。
后台统一使用模型名 astron-code-latest，底层实际模型在讯飞星辰MaaS平台网页后台一键切换，1到3分钟即生效。目前支持的国内顶尖旗舰包括：

• GLM-5.1：智谱新一代旗舰基座，长程任务能力显著提升，可自主工作长达8小时，闭环交付工程级成果，整体表现对齐Claude Opus 4.6。如果你的需求是大型项目重构、复杂智能体搭建等高强度任务，GLM-5.1是Coding Plan里最值得优先上手的新成员。
• Qwen3-Coder-Next：专为编程智能体设计的高效混合专家（MoE）模型，总参数80B，激活参数仅3B，专注于长时程、多工具、可交互的真实编程任务。日常代码补全和轻量调试的首选。
• Qwen3.5-397B-A17B：原生视觉语言模型，覆盖201种语言，在代码生成、智能体推理与多模态理解方面表现卓越，尤其适合图文混合输入或多语言场景。
• Kimi-K2.5、MiniMax-M2.5 等。

兼容主流编程工具。
提供两套接口地址，覆盖当前两大标准：

# Anthropic 协议（适用于 Claude Code）  
https://maas-coding-api.cn-huabei-1.xf-yun.com/anthropic  
  
# OpenAI 协议（适用于 OpenClaw、Cursor 等）  
https://maas-coding-api.cn-huabei-1.xf-yun.com/v2

Claude Code、OpenClaw、Cursor、OpenCode……都已支持接入。

了解了基本信息，下面直接上实操，给大家准备了两个热门Agent的保姆级接入教程。

OpenClaw接入指南

首先安装OpenClaw。最好用一台备用机来折腾。

Windows用户，在终端执行：

iwr -useb https://openclaw.ai/install.ps1 | iex

macOS用户，在终端执行：

curl -fsSL https://openclaw.ai/install.sh | bash

然后按提示完成配置，界面如下。

安装教程网上很多，这里不再赘述。打开后是下面的界面。

装好之后，配置模型。OpenClaw支持Web UI配置，个人更推荐这种方式，比直接改配置文件直观。终端输入：

openclaw dashboard

浏览器会自动弹出配置页面。