我最近在书库里翻到一篇很长的 Dev.to 文章：Anmol Baranwal 写的《Open Source Toolkit for Building AI Agents in 2026》。
表面看，它是一篇工具清单：17 个类别，几十个开源项目，从 CopilotKit、LangGraph、Deep Agents、OpenCode，到 Browser Use、Firecrawl、Docling、E2B、mem0、DeepEval、Langfuse。
但我喜欢它，不是因为它"列得全"。
真正让我停下来的是它背后那个判断：
2026 年做 AI Agent，模型已经不是主战场了。主战场正在转移到模型外围的工程栈。
过去一年，很多人谈 Agent 还停留在一句话：
给 LLM 一个目标，让它调用工具，然后循环执行。
这句话没错，但太粗了。真正把 Agent 从 demo 推到生产的人，很快会发现：模型只是内核，真正决定它能不能干活的是外面那一整圈东西——UI、工具、状态、权限、记忆、沙箱、评测、观测、分发。
Anmol 这篇文章的价值就在这里：它不是在问"哪个模型最强"，而是在问：
一个 Agent 要真的可用，外围到底需要多少层基础设施？
我读完后的感觉是：层数比想象中多。
这篇文章里最值得记住的一句话是：
Agent = Model + Harness
这里的 harness，不是一个很好翻译的词。你可以把它理解成"模型外骨骼"：工具、状态、计划、记忆、反馈循环、guardrails、文件系统、上下文压缩、子 agent 隔离、权限控制。
也就是说，Agent 不是"一个更聪明的模型"。
Agent 是一个模型，被一整套工程结构包起来之后，才开始像一个能干活的系统。
这件事有一个很硬的数据点：文章提到 LangChain 只改 harness 层，不换模型，就让同一个模型在 Terminal Bench 2.0 上从 52.8% 提到 66.5%，排名从 Top 30 进 Top 5。
这个数字的含义很大。
它说明模型能力不是固定释放的。你给它什么工具、怎么组织状态、怎么压缩上下文、怎么让它计划、怎么让它恢复错误，都会改变它实际表现出来的能力上限。
这跟我最近用 Claude Code / Codex 的体感完全一致。
很多时候，我不是缺一个更强的模型，而是缺一个更好的 harness：
模型越强，harness 反而越重要。
因为弱模型只能做短任务，强模型会开始做长任务；短任务靠 prompt，长任务靠系统。
Anmol 原文列了 17 类工具。这个清单很适合收藏，但如果你真要做 Agent 产品，不能按 listicle 的方式理解它。
为了自己能用，我先把它压成 5 层来看。
第一层：UI / 人机交互层
代表项目是 CopilotKit 和 AG-UI。
很多 Agent demo 只做后端：模型能调用工具，能返回文本。但真正的产品需要用户界面：对话框、任务进度、持久线程、human-in-the-loop、共享状态、Inspector。
Agent 不只是要"会干活"，还要让人看得懂它在干什么。
这就是 CopilotKit 这类项目的价值：它把 Agent 从黑盒调用变成可交互产品。
这里还有一个趋势：Agent UI 不会只是 chat。未来很多 Agent 会直接生成组件、表格、按钮、操作面板。AG-UI、A2UI 这些协议，本质上是在回答一个问题：
Agent 和用户之间，到底应该用什么事件格式交流？
这不是前端小问题，这是 Agent 产品化的入口。
第二层：Runtime / 编排层
代表项目是 LangGraph、Deep Agents。
LangGraph 的关键不是"又一个 Agent 框架"，而是它把循环变成图，把每一步变成 node，把状态做成 typed + checkpointed。
这听起来像工程细节，但对长任务非常关键。
一个 Agent 如果只能在一次会话里从头跑到尾，它永远很脆。真正的长任务需要暂停、恢复、重放、分支、失败后从中间继续。这些都不是 prompt 能解决的。
Deep Agents 更进一步，把长程 Agent 常见问题做成 harness：
这正是 Agent 从"会回答"变成"会执行"的关键。
第三层：Tools / 外部世界层
代表项目是 MCP、Browser Use、Firecrawl、Docling。
Agent 如果只能在 prompt 里思考，它还是一个聊天机器人。它必须能接触外部世界：浏览器、网页、API、数据库、PDF、文件系统、命令行。
这里 MCP 的位置很清楚：它是 Agent 到工具的协议。
Browser Use 解决浏览器操作，Firecrawl 解决网页抓取和结构化摄取，Docling 解决 PDF / Office 文档的结构保真转换。这些看起来"不性感"，但没有它们，Agent 就只能在空中写作文。
我现在越来越相信：
Agent 产品的上限，不取决于模型会不会推理，而取决于它能安全接触多少真实世界。
第四层：Execution / Safety 层
代表项目是 E2B、sandbox、code execution。
只要 Agent 开始写代码、跑命令、改文件，安全问题就出现了。
它需要一个地方执行代码，但不能随便碰你的主机；它需要读写文件，但不能误删项目；它需要安装依赖，但不能污染环境；它需要访问凭证，但不能长期持有你的 secret。
这就是 sandbox 和权限层的价值。
很多团队低估了这一层。因为 demo 阶段可以本地随便跑，生产阶段不行。生产里的 Agent 必须有边界：
没有 execution safety，Agent 越强越危险。
第五层：Eval / Observability 层
代表项目是 DeepEval、Langfuse。
这是 Agent 从"看起来能用"到"真的能维护"的分水岭。
传统软件有日志、测试、监控、告警。Agent 也需要这些，而且更需要。因为 Agent 的失败不是只有 crash，还有很多软失败：
没有 eval 和 observability，Agent 就是黑盒玄学。
你不知道它为什么成功，也不知道它为什么失败，更不知道模型升级后会不会把你的工作流搞坏。
这也是为什么我现在看 Agent 项目，会越来越关注它有没有评测、日志、trace、成本统计、失败分类，而不是只看 demo 视频。
这篇文章里，我最想拿回来用到 yuewei-digest 的，不是某个具体工具，而是 Deep Agents 那套上下文治理思路。
长程 Agent 最大的问题不是"上下文不够长"。
上下文再长，也会被污染、分散、塞满。
Deep Agents 的思路很直接：
不要把所有东西都塞进 prompt。
大工具输出放虚拟文件系统；skills 启动时只加载 frontmatter，完整内容按需加载；会话历史随着任务增长压缩；子 agent 在自己的上下文窗口里运行，主 agent 只拿最终结果。
这套设计背后的原则是：
主上下文只放当前决策需要的信息，其他材料都外置、索引、按需展开。
这对 yuewei-digest 很有启发。
我现在的日报系统已经在做类似事情：
这其实就是一种上下文减载。
未来如果要把 yuewei-digest 做成更 agentic 的系统，关键不是"给 Claude 更长上下文"，而是设计更好的上下文治理：
Agent 工程的核心问题，最后都会变成信息流设计问题。
这篇文章还有一个很清楚的框架：现代 Agent stack 里有三类协议。
这个拆分非常重要。
因为很多人讨论 Agent 时，把所有接口都混在一起。其实这三件事完全不同。
Agent 调工具，需要的是 schema、权限、调用结果、错误处理。
Agent 调另一个 Agent，需要的是任务委派、能力描述、状态隔离、结果交接。
Agent 面向用户，需要的是事件流、UI 状态、human-in-the-loop、可解释进度。
这三类接口会逐渐分开。
我现在看 Claude Code plugin marketplace，也会放到这个框架里看。
Claude Code plugin 不是单纯的"插件市场"。它可能同时打包：
也就是说，plugin marketplace 可能是 Agent 工程栈的分发层。
Dev.to 这篇文章讲的是 Agent 的生产资料；Claude Code plugin marketplace 讲的是生产资料的分发入口。
这两件事放在一起看，才是完整图景。
如果 2026 年 Agent 的主战场变成工程栈，那独立开发者的机会就不是"训练一个更强模型"。
那不是我们的战场。
真正的机会在更小、更具体、更靠近工作流的地方：
1. 做垂直 harness
不是做通用 Agent 框架，而是做某个场景的外骨骼。
比如：
这些系统的核心不是模型，而是流程、工具、上下文和验证。
2. 做高质量 skills
Skills 很像"可分发的方法论"。
一个好的 skill 不是几句 prompt，而是把某类任务拆成可执行步骤、输入输出格式、检查清单、失败处理、退出标准。
这跟我现在写 AGENTS.md、Codex skill、OpenCLI adapter 的经验是同一类东西：把隐性工作方法变成显性操作协议。
3. 做工具连接层
MCP / OpenCLI / browser automation / API adapter 都属于这一层。
Agent 要进入真实世界，必须有人把真实世界包装成稳定工具。这里不会只有大公司机会，小团队反而有优势，因为长尾工具太多了。
4. 做评测和观测
未来每个 serious Agent 产品都会需要：
这类东西很无聊，但会变成基础设施。
5. 做分发
Claude Code plugin marketplace、skills、MCP registry、OpenCLI adapter，这些都可能成为新的分发渠道。
独立开发者最应该关注的，不只是"我能做什么工具"，而是：
我的工具能不能被 Agent 一键发现、一键安装、一键调用？
分发层一旦稳定，早期占位的价值会很高。
这篇 Dev.to 工具清单真正给我的不是"收藏 80 个 repo"。
更准确地说，是三个会影响我接下来做东西的判断。
第一，Agent 不是模型能力问题，而是系统工程问题。
模型当然重要，但模型只是内核。真正让它变成 Agent 的，是 harness、tools、state、memory、sandbox、eval、observability。
第二，2026 年的 Agent 竞争会越来越像 Web 工程。
早期 Web 只要会写 HTML 就能做页面。后来前端、后端、数据库、缓存、部署、监控、安全、CI/CD 全部分层。Agent 也会经历同样过程。
今天大家还在争 LangGraph、CrewAI、AutoGen 哪个好，过两年大家会默认 Agent 产品就是一整套 stack。
第三，独立开发者最好的切入点不是做平台，而是做 workflow。
平台会很挤，模型会很贵，通用框架会被大公司和开源社区卷掉。
但具体工作流永远很多：
我更愿意把赌注放在这些地方。
所以我喜欢《Open Source Toolkit for Building AI Agents in 2026》，不是因为它列了很多工具。
工具清单会过期，stars 会变化，框架会轮换。
但它暴露出的趋势不会很快过期：
Agent 正在从"模型调用"变成"工程栈"。
如果粗暴地分，2024 年大家在比模型，2025 年大家在比 prompt 和工具调用。到 2026 年，真正的分水岭会越来越像 harness：谁能把 UI、工具、上下文、沙箱、评测、观测、分发这些模型外围层拼成闭环，谁才是真的在做 Agent。
这也是我接下来最想观察的方向。
不是"下一个最强模型是什么"，而是：
如果你也在做 Agent，我建议你读这篇文章时不要只收藏 repo。
更应该问自己一句：
我现在做的东西，属于 Agent 工程栈的哪一层？
如果答案只是"我调用了模型"，那还不够。
真正的机会，藏在模型外面。