2026-08-21 00:10:00
最近深度读了两个很有代表性的 Agent 项目：
它们都在解决同一个问题：怎样把“大模型 + 工具调用”变成一个能够长期运行、可以恢复、可扩展、可治理的 Agent 系统。
但读完代码后，我发现它们其实不在同一条赛道上。
DeepSeek Harness 更像一套为 Coding Agent 产品准备的可组合运行时内核；AgentScope Java 更像一套面向 Java 企业应用的Agent 框架、Harness 与服务平台。
如果只看 README，容易得出“两个项目功能差不多，只是一个用 TypeScript、一个用 Java”的结论。真正进入源码后，会看到两套完全不同的架构取向：
先说我的结论：
如果你想造一个 Coding Agent 产品，或者深度定制 Agent Runtime，DeepSeek Harness 更值得研究；如果你想把 Agent 纳入现有 Java 企业系统，并进一步做成可运营的服务，AgentScope Java 路线更直接。
在讨论这两个项目之前，先要回答一个基础问题：什么是 Harness？
一个最简单的 Agent 循环通常只有几步：
这只是 ReAct Loop。真正进入生产后，系统还要处理很多模型并不关心、但工程上无法回避的问题：
Harness 就是包围在模型循环之外的这一整层工程系统。
从这个定义看，两边虽然都叫 Harness，但边界不同。
DeepSeek Harness 的产品边界从底层事件、工具和文件系统能力，一直延伸到 Web UI、CLI、SDK 和插件开发体系。运行中的 dsh 本身就是一棵插件树。
AgentScope Java 则更明确地分成三层：
agentscope-core 提供模型、消息、工具、事件和 ReActAgent
agentscope-harness 在 Core 之上叠加工作区、记忆、压缩、技能、子 Agent、沙箱等能力agentscope-service 再向上提供 Agent 注册、Session 管理、团队编排、Dashboard 和分布式控制面所以，更准确的对比不是“框架 A 对框架 B”，而是：
一套高度可组合的 Agent 产品运行时，对比一套 Java Agent 框架及其生产服务平台。
DeepSeek Harness 最鲜明的设计不是工具多，也不是 UI 完整，而是它真的贯彻了“一切皆插件”。
底层的 Cordis 提供共享 Context、服务注册、类型化事件和可撤销副作用。模型适配器、工具注册表、会话日志、Agent Loop，甚至持久化与沙箱策略，都是挂载在同一棵树上的插件。
这意味着系统里没有一个必须不断打补丁的“神圣内核”。一个插件注册服务、工具或监听器时，这些注册都会绑定到插件生命周期；插件卸载时，副作用也会被撤销。依赖服务消失，消费它的插件会一起卸载；服务恢复后，再重新加载。
这套设计带来三个很强的能力。
传统框架常见的“可插拔”，其实只是允许你传一个接口实现。DeepSeek Harness 的粒度更细：
例如把本地文件系统和进程执行替换成 E2B provider，Shell、文件工具等消费者可以继续复用同一套上层语义。它强调的是“能力接缝”（capability seam），而不是在每个工具内部判断当前跑在本机、容器还是远端。
这很适合构建 Coding Agent：底层执行世界会变化，但上层 Agent Loop 不应该跟着分叉。
因为注册本身就是可撤销副作用，DeepSeek Harness 可以在运行时卸载、替换、重新挂载插件。配置文件变化时，Loader 会比较配置项，只重载发生变化的部分；无效的新配置不会摧毁当前可用的插件树。
这不只是“保存文件后少重启一次”。它说明这个系统从一开始就在处理一个困难问题：动态变化的能力集合，如何不留下失效引用和脏状态。
对于需要安装第三方插件、切换 Agent Profile、运行不同产品形态的系统，这个底座很有价值。
DeepSeek Harness 把事件分成三个域：
agent/* Event：正在运行的 Agent 状态与控制例如工具执行不是简单调用一个函数，而是经过：
pre-execute → 单调守卫 → execute → post-execute → finalize → result
审批、沙箱、超时、重试、指标、结果改写都可以挂在流水线上，不必让具体工具直接依赖这些策略。
这类设计的好处是扩展面非常清楚；代价则是概念多、学习曲线陡。你必须理解 Context、Service、Effect、Scope、Waterfall Event、Profile、Bundle 和 Patch，才能真正驾驭它。
我认为 DeepSeek Harness 最有含金量的部分，不是插件，而是它对 Session 的定义。
它把会话建模为一份只追加的事件日志。turn/start、step/start、用户消息、模型流式 chunk、完整 assistant message、工具调用、工具结果和结束边界都会进入日志。
模型看到的上下文不是另一份独立状态，而是通过 deriveMessages() 从日志投影出来。
它甚至把原则写得非常直接：
模型可见即已记录。
这句话很重要。很多 Agent 系统同时维护三份相似但不完全一致的状态：
一旦三者漂移，就会出现最难查的 Agent Bug：界面上看到了某条消息，但模型没看到；模型根据某段隐藏上下文做了决定，但重启恢复后这段上下文丢了。
DeepSeek Harness 试图从结构上消灭这种分叉。原始流式 chunk 保证 UI 可以精确回放；完整消息用于派生模型历史；压缩通过 surface replacement 表达；fork、resume、transcript 和 telemetry 都从同一事件流产生。
Crash Recovery 也遵循这个思路：如果载入时发现一个 turn/start 没有对应的 turn/end，系统不会粗暴截断已经持久化的长任务，而是补上一个 interrupted 结束事件，保留中断前已经发生的事实。
这种做法更像事件溯源系统，而不是传统聊天记录。
它的收益是：
但它也把兼容性压力集中到了事件协议上。当前 Session 格式版本仍是 0，官方明确表示没有兼容承诺；一旦事件含义变化，迁移就会成为非常严肃的问题。
工具调用是比较两个项目时最能体现设计差异的地方。
DeepSeek Harness 会为每一个待执行调用查询 executionMode：
parallel 可以与相邻安全调用重叠exclusive 必须独占执行，并形成顺序屏障Agent Loop 使用滚动并发池执行安全调用，同时保证结果仍按模型调用顺序写回。更关键的是，分类发生在调用级，而不只是工具级。理论上，同一个工具可以根据本次参数判断它是只读操作，还是需要独占的写操作。
它的工具流水线还把权限、单调守卫、沙箱、超时、重试、结果规范化和持久化观察分开。任何一层失败，都要被转成唯一、可记录的最终结果。
AgentScope Java 2.0 的 Toolkit 默认开启并行执行。工具可以通过 concurrencySafe 标记自己是否能安全并发；连续的安全工具会并发运行，不安全工具形成串行槽位，输出顺序仍然保留。
这已经比“整个批次要么全并行、要么全串行”细很多，也很符合 Java 工程团队的使用习惯。但它当前主要还是工具定义级标记，表达力不如 DeepSeek Harness 的调用级动态分类。
因此，如果你在做文件编辑、终端、数据库变更这类副作用复杂的 Coding Agent，DeepSeek Harness 的执行语义更精细；如果大多数工具本身就是业务 API，AgentScope 的模型更直接，也更容易让普通团队理解。
DeepSeek Harness 还有一个很有辨识度的能力：Code Mode。
普通 Function Calling 会把每个工具的完整 JSON Schema 暴露给模型，模型每调用一次工具，结果又会进入对话上下文。工具一多，Schema 和中间结果会持续占用 Token。
Code Mode 则只向模型暴露一个 run_code 入口和一份自动生成的 TypeScript 或 Python SDK。模型在临时程序中调用：
1 2 3 4 5 |
|
中间工具结果留在本次执行局部，只有 return 或 console.log 的内容回到模型上下文。
这带来的价值不是“模型会写代码”——Coding Agent 本来就会——而是：
它本质上是把一部分 Agent 编排从自然语言推理迁移到一次性的确定性程序中。
不过 Code Mode 也不是免费午餐。当前每次运行都是全新状态，不是持久 REPL；中间值不能从会话日志重建，而且执行局部没有统一字节上限。如果程序拿回超大对象，仍然可能造成 worker 内存压力。
如果说 DeepSeek Harness 的关键词是“可组合”，AgentScope Java 的关键词就是“可运营”。
它的双层 Agent 结构很清楚。
ReActAgent 负责核心推理循环，把模型、Toolkit、权限、Middleware、事件和 AgentState 组合起来；HarnessAgent 是外层包装，通过固定顺序的 Middleware 和工具，增加工作区、长期记忆、上下文压缩、技能、子 Agent、沙箱和 Plan Mode。
这种设计没有追求“一切皆插件”的纯粹性，而是刻意保留一个容易使用的 Builder：
1 2 3 4 5 |
|
对于 Java 团队，这种体验很熟悉：核心抽象稳定，基础设施通过 Builder 和 Spring Boot Starter 接入，扩展行为走 Middleware。
更重要的是，AgentScope Java 没有停在 SDK 层。仓库中的 agentscope-service 已经把 Agent 运行进一步拆成 Gateway、Control Plane、Dataplane 和 Scheduler，并提供 Dashboard、Managed Agents 与 Agent Teams。
因此它真正想解决的不是“如何写出一个聪明的 Agent”，而是：
一家公司里有很多 Agent、很多用户和很多运行副本时，怎样统一注册、恢复、观察、调度和治理。
两边都重视持久化，但设计中心不同。
DeepSeek Harness 以 append-only Session Event Log 为 Source of Truth。状态恢复、模型历史和 UI 展示尽量从事件投影得到。
这是偏运行时语义的选择：重点是“过去到底发生了什么”。
AgentScope Java 把状态分成几层：
RuntimeContext：当前调用的 userId、sessionId 和临时属性，不持久化AgentState：对话上下文、权限、Plan Mode 和工具状态，通过 AgentStateStore 跨调用恢复MEMORY.md
同一个 Agent 实例可以服务多个用户和会话。系统通过 (userId, sessionId) 定位状态；同一 Session 的调用串行化，不同 Session 可以并行。再配合 Redis、MySQL、PostgreSQL、OSS 或 COS 等后端，实例本身可以保持无状态并水平扩容。
这是偏服务架构的选择：重点是“下一次请求由任何副本接手时，怎样继续运行”。
两种模型没有绝对高下。
DeepSeek Harness 的本地 Sandbox 更贴近开发者桌面和 Coding Agent。Linux 可使用 bubblewrap / Landlock，macOS 使用 Seatbelt，Windows 有 ACL restricted-token runner。它强调同一宿主执行世界里的文件写入边界，并且在无法落实策略时 fail closed，而不是悄悄降级为无限制执行。
远端执行则不被塞进同一个进程沙箱接口，而是通过替换文件系统与进程 provider，把整个执行世界一起移动。目前仓库也已经提供 E2B 的文件系统和进程实现。
AgentScope Java 的沙箱更偏服务部署。它把 Docker、Kubernetes、Daytona、E2B 和 AgentRun 视为同类后端，并进一步考虑：
所以，DeepSeek Harness 更关心“这条命令在当前执行世界里是否越界”；AgentScope Java 更关心“这个租户的执行环境能否隔离、持久并被另一台机器接手”。
DeepSeek Harness 把 Subagent 做成可替换 capability seam。不同 provider 可以在同一 Context 共存：进程内 spawn、基于历史 fork，以及对接 Codex、Claude Code、ACP 或 DSH SDK 的外部执行器。
它还区分一次性子 Agent 和可继续对话的子 Agent。后者拥有持久 Session、可冷恢复的 Activation、唯一 inbox 和明确的父子授权关系。实验性的 Agent Teams 则在其上增加 roster、task board 和 mailbox。
AgentScope Java 的多 Agent 更贴近业务使用：
agent_spawn 创建同步或后台子任务agent_send 向已创建的子 Agent 继续发消息简单说，DeepSeek Harness 优先解决的是“如何把不同 Subagent 实现放到同一个抽象后面”；AgentScope Java 优先解决的是“如何让一组 Agent 在企业平台里持续协作”。
| 维度 | DeepSeek Harness | AgentScope Java |
|---|---|---|
| 核心定位 | 可组合 Agent Runtime 与产品底座 | Java Agent 框架、Harness 与服务平台 |
| 技术栈 | TypeScript / Node.js，含 Web、Native 与 Python SDK | Java 17 / Reactor / Maven / Spring Boot，Service 含 Go 与前端 |
| 核心抽象 | Cordis Context、Plugin、Service、Event、Effect、Scope | Agent、ReActAgent、HarnessAgent、Middleware、RuntimeContext、AgentState |
| 执行循环 | Turn / Step 边界明确，行为大量通过事件拦截 | ReAct 核心循环稳定，Harness 通过 Middleware 叠加能力 |
| 状态真相 | Append-only Session Event Log | AgentStateStore + Session Log + Workspace / Memory |
| 回放能力 | 强，原始 chunk、调用与结果都进入事件日志 | 更偏事件流展示和状态恢复，不以统一事件溯源为核心 |
| 工具并发 | 调用级 parallel / exclusive 分类与屏障 |
Toolkit 批量并发，工具级 concurrencySafe 标记 |
| 工具扩展 | 多阶段 waterfall、守卫、审批、沙箱、结果规范化 | Toolkit、权限系统、Middleware、执行配置 |
| Code Mode | 原生支持 TypeScript / Python 工具编排 | 不是当前核心设计 |
| 沙箱 | 本机强制隔离 + E2B provider，可替换整个执行世界 | Docker / K8s / Daytona / E2B / AgentRun，快照与分布式锁完整 |
| 多 Agent | 多 provider、一次性与可继续子 Agent、实验性 Teams | 同步/后台子 Agent、持久任务、Teams 与控制面 |
| 企业集成 | 需要自行组合和建设 | Redis、MySQL、PostgreSQL、OSS、COS、Nacos、Spring Boot、Channel |
| 产品形态 | CLI、Web、Headless、SDK、插件 Profile | Core、Harness、Extensions、Service、Dashboard |
| 当前成熟度 | 0.1.0-rc.8，Developer Preview |
2.0 已 GA，主干继续快速迭代 |
它的风险主要有三个。
第一，项目仍处于 Developer Preview，当前版本是 0.1.0-rc.8，官方明确提示后续会有破坏性变化。Session 格式也是预发布的 v0，没有内置迁移链。
第二，Cordis 的抽象能力很强，但认知成本也高。插件树、Service 注入、Scope 隔离、Effect 回收、Waterfall Event、Bundle 和 Patch 共同工作时，调试难度不低。
第三，它更像一个完整产品底座，而不是一个轻量 SDK。如果团队只是想在已有业务里增加几个 Agent 能力，引入整套运行时未必划算。
AgentScope Java 的风险也很明显。
首先，ReActAgent 和 HarnessAgent 都已经是体量很大的中心类。大量能力虽然通过 Middleware、Toolkit 和 Builder 暴露，但编排与兼容逻辑仍集中在核心实现里。未来功能继续增加时，维护成本值得关注。
其次，它的“可扩展”更接近企业框架的扩展方式，而不是 DeepSeek Harness 那种运行时级可替换。你可以加 Middleware、工具和 Store，但很难像 Cordis 一样把整个 Agent Loop 当成普通插件换掉。
最后，AgentScope Service 已经覆盖控制面、托管运行时和 Teams，能力很诱人，但这也意味着更重的部署和运维成本。只有当组织真的存在多 Agent、多租户、多副本和统一治理需求时，这一层平台才有足够回报。
如果你的目标是下面这些，优先研究 DeepSeek Harness：
如果你的目标是下面这些，优先考虑 AgentScope Java：
还有一种常见情况：团队只是验证一个小型 Agent 功能。
这种时候，两套方案都可能太重。直接使用简单的模型 SDK、少量工具和一个清楚的状态边界，往往更合适。不要因为 Harness 很先进，就默认所有 Agent 都需要 Harness。
DeepSeek Harness 展示的是一种 Runtime-first 路线：
把 Agent 的每一项能力都变成可组合、可替换、可回收的运行时部件，再用统一事件日志保证执行语义。
AgentScope Java 展示的是一种 Production-first 路线：
把 Agent 纳入成熟的应用服务体系，解决租户、状态、沙箱、存储、渠道、调度和控制面，再让企业真正运营它。
前者更像在设计 Agent 时代的“运行时内核”，后者更像在建设 Agent 时代的“应用服务器与控制平台”。
两边最终很可能会互相靠近：DeepSeek Harness 会继续补生产基础设施，AgentScope Java 也会继续细化运行时语义。但至少在当前阶段，选型边界非常清楚：
造 Agent Runtime 和产品，选 DeepSeek Harness；在企业系统里运行和治理 Agent，选 AgentScope Java。
这也说明 Agent 开发已经进入了一个新阶段。竞争不再只是“谁的模型更聪明”或“谁的 Demo 工具更多”，而是：
谁能把不确定的模型行为，装进一套可恢复、可解释、可扩展、可治理的软件系统。
本文阅读基线为 2026 年 8 月 21 日，主要参考两个仓库当时的主干源码与文档：DeepSeek Harness 141eb6f（0.1.0-rc.8）和 AgentScope Java 643905e。关键资料包括 DeepSeek Harness 架构、Agent 生命周期、工具执行流水线、AgentScope Harness 架构、AgentScope Agent 与 AgentScope Service。
2026-08-06 11:28:00
最近一直在深度思考和实践“企业如何实现 AI Native”。
在看了大量架构方案、也踩了不少落地坑之后，我越来越确信一件事：AI Native 绝不是买几个大模型账号，也不是强行造一个新系统给员工用。
如果脱离了企业的真实数据生态和员工的习惯路径，所谓的 AI Native 改造只是一场昂贵的“技术自嗨”。
今天把最近关于 AI Native 落地的前提、短中期痛点、协同载体以及终局形态的思考梳理出来，供大家参考。
在探讨具体协同载体之前，我们先拉高视角，看一张企业级 AI Native 落地全景架构图。
整个架构从上到下分为应用场景层、能力解耦层、核心 Runtime 运行时以及底座资源支撑层：
这张架构图体现了两个核心逻辑： 1. 能力解耦与治理（Skill/MCP Hub）：将数据、工具和系统能力标准化暴露，解决安全鉴权与复用问题。 2. 场景双轮驱动：既包含了研发侧的 Vibe Coding，也涵盖了全公司业务与职能形态的 Agent 化。
后文讨论的所有“Agent Readable”、“IM 协同”以及“私有 Runtime”，本质上都是这张架构图在具体工程和组织管理中的落地延伸。
绝大多数企业在喊 AI Native 时，第一步就卡住了。
原因很简单：大模型虽然聪明，但它对企业内部的真实情况一无所知。
企业要真正走向 AI Native，第一个关键基础设施不是选哪个模型，而是实现 Agent Readable（Agent 可读化）：
只有企业的核心数据、知识与资源变成了 Agent 可以安全获取、读取和理解的形式，AI Native 的改造才有底座。
很多人对 AI Native 抱有不切实际的幻想，认为一旦引入立刻就能全员提效。
现实往往相反：短期内，AI Native 改造大概率是降效的。
引入新技术必然带来额外的成本：
管理者必须有清醒的认知：短期内我们在为“认知升级和工程基础设施”买单，长期来看，当 Agent 能够自主吞吐数据与执行流程时，指数级的提效才会真正爆发。
最近观察到飞书、钉钉、企微等办公软件频繁调整组织架构和 AI 战略，这与我们探索的“企业 Workspace”方向完全吻合。
未来企业真的需要为了 AI 专门再开发一套全新的协作平台吗？答案大概率是：不需要，甚至应该坚决避免。
重新造一个新平台，面临最大的阻力就是用户习惯路径的迁移。而钉钉/飞书/企微有着得天独厚的优势：
虽然用户界面不需要自研，但这并不意味着企业不需要自己的基础设施。
从数据安全性、模型路由与 Runtime 多样性的角度来看，企业必须拥有私有的 Agent 运行与治理能力。
因此，理想的终局形态是明确的解耦：UI 交互层归办公 IM，运行治理层（私有大脑）归企业自建。
试想这样一个未来的产研闭环场景：
@产品经理 Agent：“我们需要增加一个根据用户行为自动生成周报的功能。”@研发 Agent。@产品经理 Agent 验收。在这个过程中：
@ 介入打断或修正。总结来看，企业 AI Native 改造的底层主线已经非常清晰：
打破幻想，扎实建设基础设施，才能真正拥抱 AI Native 的时代。
2026-05-17 11:44:00
最近大量使用 AI 进行开发，我逐渐意识到一个趋势：随着 AI 编程的普及，被颠覆的不仅仅是一线工程师的工作方式，对 CTO、技术总监、技术 Leader 这些技术管理者的要求，正在发生截然不同的改变。
过去，技术管理的核心在于“人”与“确定性”；而现在，当 AI 开始接管代码生成，系统正在变得“非确定性”。如何理解和控制这种非确定性，将成为下一代技术管理者的核心壁垒。
在传统的软件工程时代，代码由工程师一行行敲出来，系统严格按照设定的逻辑执行。
这种模式下，系统是高度确定性的：输入相同，输出必然相同。如果出了 Bug，顺着调用栈一层层 Debug，总能找到引发异常的那行代码。因此，技术管理者不需要每天盯着系统的细枝末节，核心精力主要放在以下三件事：
当研发流程全面接入 AI，情况变了。
现在是工程师设计约束，AI 负责生成代码。这种模式打破了传统的确定性——同样的输入，AI 每次给出的实现细节可能完全不同。这带来了一系列连锁反应：
在这样的背景下，技术管理者的核心工作，正在从单纯的“管人”向“管系统行为”演进。未来的首要任务，是解决“如何完全理解系统为什么这么运行”的问题。
技术管理者的新角色正在转变为：
本质上，AI 时代的研发管理，需要建立一套全新的认知框架。
从管理“人类开发者的产能”，升级为管理“人机协同系统的行为边界”。对现有的技术管理者来说，这不仅是脱离舒适区的巨大挑战，更是抓住下一次技术代差、重塑团队战斗力的绝佳机会。
2026-04-06 00:17:00
很多人开始配置自己的 Agent 时，都会很快遇到一个问题：
SOUL.md 和 AGENTS.md 看起来都像是在“定义 Agent”，它们到底有什么区别？
如果这两个文件不分清，后面就很容易出现一种典型混乱：人格写进岗位说明，业务流程写进行为准则，文件越写越多，Agent 反而越来越不像一个稳定的助手。
先说结论：
SOUL.md 负责定义 这个 Agent 怎么做人、怎么做事、什么不能碰
AGENTS.md 负责定义 这个 Agent 是干什么的、服务谁、交付什么、按什么流程工作
一句话：
SOUL.md 是灵魂，AGENTS.md 是岗位说明书。
原因其实很简单：这两个文件都在描述 Agent，而且都不是技术配置项，而是自然语言规则。
于是很容易出现下面这种误写：
SOUL.md 里写“每周发 3 篇小红书”AGENTS.md 里写“说话别太啰嗦，先给结论”表面上看都能运行，但问题在于：
这就像你在公司里把“企业文化”和“岗位 KPI”写进同一张纸。
短期看没事，长期一定乱。
SOUL.md 适合放什么SOUL.md 更适合放那些跨任务长期有效的行为原则。
也就是：不管这个 Agent 今天在写文章、查资料、做排期，还是和你对话，它都应该稳定遵守的那一层规则。
它更像下面这些问题的答案：
它适合放的内容，大致可以分成 4 类：
比如：
比如：
比如：
比如：
这些东西有一个共同点：
它们不依赖具体业务，而定义的是这个 Agent 的稳定人格和做事方式。
AGENTS.md 适合放什么如果说 SOUL.md 解决的是“怎么做人”，那么 AGENTS.md 解决的就是“你到底是干什么的”。
它更适合放那些业务身份、职责范围、目标、流程和输出物。
它更像下面这些问题的答案：
通常来说，AGENTS.md 更适合放 5 类内容。
比如：
比如：
比如：
比如：
比如：
这些内容有一个共同点：
它们定义的是这个 Agent 的工作岗位，而不是性格。
如果你拿到一条规则，不知道该放哪，就问自己一句：
它到底在回答“我怎么做事”，还是“我做什么事”？
放进 SOUL.md。
例如：
放进 AGENTS.md。
例如：
这是区分这两个文件最省脑子的办法。
SOUL.md
很多人喜欢把一切“对 Agent 的要求”都堆进 SOUL.md，因为它名字听起来更高级。
但这会带来两个问题：
SOUL.md 变成一个无边界的大杂烩AGENTS.md 反而变空，只剩一句角色介绍这样做的后果是，Agent 会越来越像“有很多态度，但没什么明确职责”。
反过来也一样。
如果你把所有业务流程和 KPI 都塞进 AGENTS.md，却不定义风格和原则，那 Agent 通常会变成另一个问题：
所以真正合理的方式，不是二选一，而是：
SOUL.md 负责“人格和准则”AGENTS.md 负责“业务和工作”两者配合，Agent 才会既稳定，又有明确产出。
最简单的模板可以是这样。
SOUL.md只保留 4 类：
AGENTS.md只保留 5 类：
如果你按这个思路来写，后面维护会轻松很多。
因为每次新增规则时，你都知道自己是在改：
这两个东西一旦分清，整个 Agent 配置就会明显稳定下来。
Agent 配置这件事，表面上看是在写几个 Markdown 文件，本质上其实是在回答两个问题：
前一个问题，交给 SOUL.md。
后一个问题，交给 AGENTS.md。
如果你把这两个文件的边界理顺了，后面很多配置问题都会变简单。
因为你终于不是在“堆规则”，而是在真正地设计一个有灵魂、也有岗位职责的 Agent。
2026-03-31 01:10:00
过去一年，围绕 AI Agent 的讨论大多集中在模型能力本身。
但如果把最近几篇有代表性的内容放在一起看，一个更关键的变化已经出现：AI Agent 的竞争重心，正在从“模型能力展示”转向“工程系统能力”。
这里的“工程系统能力”，不是一句空话。它至少包含四层：
如果只记一条：2026 年的 Agent，已经不再只是“大模型 + 工具调用”，而是在走向一套完整的软件工程体系。
以 Cursor 发布 Composer 2 为例，这类发布最容易被表面解读为“又一个新模型上线”。但如果只盯着 benchmark 分数，其实会错过真正重要的信息。
真正值得关注的是：垂直场景优化，正在从提示词层面的工程技巧，变成底层模型层面的产品策略。
过去大家默认的路径是：
而现在，越来越多产品开始反过来做：
在代码生成领域，这个逻辑尤其成立。因为对开发者来说，关键指标从来不是“会不会聊天”，而是：
所以代码模型的价值，不在于“像人一样懂很多”，而在于“在狭窄但高价值的任务里做到足够可靠”。
从工程视角看，这一步非常重要。因为一旦模型专用化开始成立，系统设计就会自然进入下一阶段：
一句话：模型层一旦专用化，Agent 系统就不再是单核结构，而开始具备多能力模块化特征。
如果模型层的关键词是“专用化”，那么框架层的关键词就是“生产化”。
以 AgentScope Java 这类框架为代表，可以明显看到一个趋势：企业级 Agent 框架的卖点，已经从“快速做 Demo”转向“纳入生产治理体系”。
一个 Demo 能跑起来，解决的是“能不能演示”；而一个生产系统能跑下去，解决的是另一组完全不同的问题：
这些问题很少出现在社交媒体上的 Agent 演示视频里，但它们决定了系统是否能进入真实业务。
这也是为什么 Java 框架在企业 Agent 讨论里开始重新获得存在感。不是因为 Java 在模型创新上领先，而是因为大量企业核心系统、权限体系、服务治理体系本来就在 Java 世界里。谁更容易接入这些系统，谁就更容易跨过“从试验到生产”的门槛。
从架构角度看，生产化框架至少意味着三件事。
它可能被启动、暂停、中断、恢复、观察、接管。这说明 Agent 已经不再是单纯的“函数调用”，而更接近“状态化任务单元”。
生产环境里，最终结果固然重要，但更重要的是：
没有过程可见性，就没有治理能力。
企业不会为了 Agent 重写整套权限和运维体系。真正可落地的框架，必须反过来适应既有系统，而不是要求企业围着 Agent 转。
因此，从这一步开始，Agent 就越来越像软件基础设施问题，而不是一个单独的 AI 功能问题。
过去一段时间，“多智能体”几乎成了 Agent 讨论里的政治正确。但真正有实践经验的团队，反而越来越强调另一条原则：Single Agent First。
这个原则看起来保守，其实非常工程化。原因很简单：多智能体架构虽然听起来强大，但它天然会引入新的系统成本：
如果业务复杂度还没高到需要这些机制，那么多智能体带来的收益，很可能不足以覆盖它引入的复杂度。
因此，更合理的路径不是“先上多智能体，再想办法降复杂度”，而是：
这个“阈值”通常出现在几类场景：
这意味着，多智能体的本质不是“更聪明”，而是更适合处理复杂系统中的职责拆分与流程编排问题。
从这一点看，多智能体更像微服务演进中的服务拆分：
当模型专用化、框架生产化、架构分层化之后，会自然冒出下一个问题：多个 Agent 之间如何协作？
如果没有标准协议，所谓“多智能体”很容易退化成一种脆弱的私有编排：
这也是 A2A 这类协议值得关注的原因。它的价值，不是又发明了一个新缩写，而是试图回答协作系统里最基础的几个问题：
这件事为什么重要？因为它标志着“上下文工程”的边界正在上移。
过去谈上下文工程，大家主要关注的是：
但在多 Agent 系统里，这些问题不再只发生在“人和模型之间”，还发生在“Agent 和 Agent 之间”。
于是新的工程问题出现了：
当这些问题成为主问题时，Agent 系统的本质就已经变了。它不再只是“一个大模型加若干外挂工具”，而是在向“分布式协作系统”靠近。
把前面四层连起来，可以看到一条非常清晰的演进链路：
这四者不是并列关系，而是递进关系。
因为一旦你开始使用专用模型，就会需要调度；一旦你进入调度，就会需要框架与治理；一旦任务复杂度提高，就会需要角色拆分；一旦角色拆分发生，就会需要标准化协作协议。
所以今天讨论 Agent，最容易犯的错误，就是仍然把它理解成一个单点能力增强工具。实际上，它正在逐步变成一套软件系统的基础设施层。
从这个意义上说，Agent 的下半场竞争，本质上是软件工程能力的竞争。
如果这个判断成立，那么技术团队下一步最值得做的，不是继续沉迷“模型榜单更新”，而是反过来重建自己的落地顺序：
不要先问“哪个模型最强”，要先问：
没有任务边界，讨论 Agent 架构几乎一定会失真。
先验证这几个东西：
很多“多智能体需求”，最后会发现其实是“单智能体上下文和工具设计没做好”。
包括：
这些能力越晚补，代价越大。因为它们通常不是外挂功能，而是会反向影响你的框架选择与系统边界。
如果只看单个新闻，最近这些变化看起来是分散的：一个代码模型升级了，一个 Java Agent 框架火了，一篇多智能体选型文章刷屏了，又出现了新的协作协议。
但把它们放在一起，就会看到更本质的趋势：AI Agent 正在从“可演示的智能能力”，演化成“可治理、可扩展、可协作的软件系统”。
这意味着接下来的竞争，不只是“谁更聪明”，而是：
对于真正做落地的人来说，这反而是个好消息。因为从这一刻开始，Agent 不再只是模型厂商的游戏，而重新变成了系统设计者、架构师和工程团队的主战场。
2026-03-24 16:36:02
很多团队在接 OpenClaw Gateway 时，第一反应是：到底该用哪个接口？
答案不是“哪个更新就用哪个”，而是看你的目标：是先把能力接入，还是把系统做成可控、可观测、可治理的平台。
如果你只记一条：Chat Completions 适合快接入，OpenResponses 适合复杂编排，Gateway WS 适合平台控制面。
本文按工程落地视角，把三种协议放到同一张决策图里讲清楚。
先明确一个问题：同一个 Gateway 为什么要提供三种接口？
这是“分层设计”而不是“重复造轮子”——兼容层负责接入效率，原生协议负责控制力与系统治理。
这是 OpenClaw 的原生控制面协议。客户端通过 WebSocket 握手（connect），声明 role/scopes/caps，然后以 req/res/event 方式通信。
它最适合做：
一句话：最完整，但接入门槛最高。
/v1/chat/completions）这是面向存量生态的兼容接口。你已有 OpenAI SDK 或上层框架时，几乎可以低改造迁移。
它最适合做：
一句话：上手最快，迁移成本最低。
/v1/responses）这是更现代的兼容接口，强调 item 化输入、工具回合、多模态输入（文件/图片）和更细颗粒度的流式事件。
它最适合做：
一句话：语义更完整，适合复杂场景。
选 Chat Completions。
原因：复用现有 SDK，改造最小，最快出结果。
选 OpenResponses。
原因：输入输出语义更现代，工具回合、多模态、事件流更顺手。
选 Gateway WS。
原因：只有原生协议能把角色、权限、节点能力、审批、配置纳入一套统一治理模型。
目标：验证价值，不纠结架构完美。
目标：提升工具编排能力和事件可观测性。
目标：统一权限、审批、配置与节点编排，做成平台而不是脚本集合。
OpenClaw Gateway 三种接口不是替代关系，而是分层协作关系。
对工程团队来说，真正重要的不是“选哪个最先进”，而是：
这才是协议选型的终局。
