文章目录
- [1 先聊聊Agent圈的"黑盒老毛病"](#1 先聊聊Agent圈的“黑盒老毛病”)
-
- [1.1 那些被焊死在源码里的核心逻辑](#1.1 那些被焊死在源码里的核心逻辑)
- [1.2 DSH的野路子：没有特权核心，全是普通插件](#1.2 DSH的野路子：没有特权核心，全是普通插件)
- [2 核心机制一：插件------自带说明书的乐高块](#2 核心机制一：插件——自带说明书的乐高块)
-
- [2.1 插件的本质：一个函数搞定一切](#2.1 插件的本质：一个函数搞定一切)
- [2.2 上手到底有多简单](#2.2 上手到底有多简单)
- [3 核心机制二：生命周期与副作用------来得干净，走得也干净](#3 核心机制二：生命周期与副作用——来得干净，走得也干净)
-
- [3.1 插件系统的老大难：卸载清理](#3.1 插件系统的老大难：卸载清理)
- [3.2 Cordis的解法：副作用全追踪，自动回滚](#3.2 Cordis的解法：副作用全追踪，自动回滚)
- [3.3 什么时候要手动写effect](#3.3 什么时候要手动写effect)
- [4 核心机制三：服务------插件之间的接头暗号](#4 核心机制三：服务——插件之间的接头暗号)
-
- [4.1 插件协作绝不能硬import](#4.1 插件协作绝不能硬import)
- [4.2 换实现，消费者一行代码都不用改](#4.2 换实现，消费者一行代码都不用改)
- [5 核心机制四：事件------插件的神经系统](#5 核心机制四：事件——插件的神经系统)
-
- [5.1 服务搞不定的，事件来补](#5.1 服务搞不定的，事件来补)
- [5.2 四种事件模式，各有各的用处](#5.2 四种事件模式，各有各的用处)
- [5.3 实战：想拦就拦的Agent循环](#5.3 实战：想拦就拦的Agent循环)
- [6 核心机制五：可配置插件------用配置文件拼乐高](#6 核心机制五：可配置插件——用配置文件拼乐高)
-
- [6.1 不用写代码也能定制Agent](#6.1 不用写代码也能定制Agent)
- [6.2 连产品形态都是配置出来的](#6.2 连产品形态都是配置出来的)
- [7 这套架构到底香在哪](#7 这套架构到底香在哪)
-
- [7.1 零fork就能扩展核心](#7.1 零fork就能扩展核心)
- [7.2 热插拔安全又省心](#7.2 热插拔安全又省心)
- [7.3 依赖关系自动管理](#7.3 依赖关系自动管理)
- [7.4 配置就是产品形态](#7.4 配置就是产品形态)
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看， 传送门https://blog.csdn.net/H1727548
1 先聊聊Agent圈的"黑盒老毛病"
1.1 那些被焊死在源码里的核心逻辑
现在市面上主流的Agent框架，路子基本都一个样。
给你一个固定的核心引擎，外面挂点工具、模型适配器让你折腾。说白了就是精装修交付的房子，你换个挂画、改个墙面颜色没问题，想挪承重墙？门都没有。
想换个Agent循环的调度逻辑？你得fork整个仓库自己改。想换个会话存储方式？对不起，核心代码写死了，碰都碰不了。
你以为你在用框架，其实是框架把你框得死死的。
1.2 DSH的野路子：没有特权核心，全是普通插件
DeepSeek Harness偏不按这个套路出牌，直接喊出"一切皆插件"。
模型适配器是插件，工具注册表是插件，会话日志是插件，连驱动整个Agent跑起来的核心循环，都是个平平无奇的普通插件。
撑起来这套玩法的，就是底层的Cordis元框架。说穿了它就干三件事：管插件的加载卸载、管服务依赖、管事件分发。
剩下所有Agent的业务逻辑，全在它上面以插件形式堆出来。
最狠的是，所谓的"官方核心插件"和你自己写的第三方插件，地位完全平等。你写个插件就能把官方核心组件换掉，不用提PR，不用等审核，插上就能用。
2 核心机制一：插件------自带说明书的乐高块
2.1 插件的本质：一个函数搞定一切
在Cordis里，插件没那么多花里胡哨的概念。
它本质就是一个函数，接收一个上下文ctx，然后在里面干自己的活。就这么简单。
官方支持三种写法，纯函数、带依赖声明的对象、类写法，看着形式不一样，运行起来完全等价。核心约定就一个：得有个apply入口，把ctx传进去。
不用继承基类，不用实现接口，不用往全局注册表报备。拿到ctx，你就能监听事件、注册工具、提供服务，剩下的脏活累活框架全给你兜着。
2.2 上手到底有多简单
举个很常见的需求：给Agent加个工具调用的审计日志。
搁别的框架，你可能得翻半天文档找钩子，甚至改源码。在这？十几行代码写个插件，监听工具执行前的事件，打条日志就完事了。
就像给家门装个监控，不用拆门改锁，粘上去就能用。
3 核心机制二：生命周期与副作用------来得干净，走得也干净
3.1 插件系统的老大难：卸载清理
很多人只关心插件怎么加载得快，很少有人琢磨怎么卸载得干净。
一个插件跑起来，注册五六个事件监听器、开俩定时器、连一个数据库、注册仨工具都是常规操作。卸载的时候漏清一个，就是实打实的内存泄漏。
传统方案是让开发者自己写cleanup方法，可谁还没个忘事的时候？这就像退租打扫卫生，总有个角落的垃圾你想不起来扔，最后全算在房东头上。
3.2 Cordis的解法：副作用全追踪，自动回滚
Cordis直接把所有副作用收口到ctx.effect()这个原语里，框架自动帮你追踪和回滚。
每个插件都会被包装成一个Fiber实例，有自己完整的状态机：等依赖、加载中、运行中、卸载中、已卸载，整得明明白白。
你注册副作用的时候，顺手返回个撤销函数。等插件卸载的时候，框架自动按后进先出的顺序，挨个给你撤销干净。
为啥要后进先出？因为后面注册的副作用，可能依赖前面注册的东西。倒着拆才不会拆出问题，就像搭积木得从上往下拆，从底下抽那不直接塌了？
3.3 什么时候要手动写effect
给大家整个好记的口诀。
只要是Cordis自己的API创建的东西，不用管，卸载自动清；只要是外部资源，比如定时器、数据库连接、文件监听、HTTP服务，就得手动包effect。
记不住也没关系，等出内存泄漏排查到秃头的时候，你自然就记住了。
4 核心机制三：服务------插件之间的接头暗号
4.1 插件协作绝不能硬import
插件之间要协作，总不能直接import对方的代码吧？
硬耦合一绑死，哪天对方换实现了，你这边直接崩成碎片，那还叫什么插件化。
Cordis里的插件协作，全靠服务来牵线。这不是什么可选的设计模式，是整个插件体系的根本协作方式。
你通过ctx.xxx用别人的能力，就是在消费服务；你通过ctx.provide注册能力，就是在提供服务。
说白了，大家只认服务名，不认具体是谁实现的。就像你点外卖，只看菜单上有啥菜，不用管今天是哪个厨师炒的。
4.2 换实现，消费者一行代码都不用改
一个服务的完整生命周期分三步：先定义接口契约，告诉大家这个服务能干啥；然后有人写实现，注册到对应的服务名上；最后消费者声明依赖，直接用就行。
框架会自动帮你排加载顺序，依赖的服务没就绪，你的插件就老实在那等着，啥时候准备好了啥时候启动。
最爽的是换服务实现的时候，消费者一行代码都不用改。
比如默认文件系统是本地的，你写个插件把fs服务换成远程沙箱的实现，原来的Bash、文件编辑这些工具，自动就跑到远程沙箱里跑了，它们自己都不知道自己换了运行环境。
这波就叫：换了厨子，菜名没变，吃饭的人啥也不用改。
5 核心机制四：事件------插件的神经系统
5.1 服务搞不定的，事件来补
服务解决的是"我要调用某个能力"的问题，但还有一类需求，服务是搞不定的。
比如模型请求前查敏感词，工具执行后记耗时，对话结束前判断要不要再来一轮。这些不是调用能力，是在关键节点拦截或者观察，就得靠事件系统。
5.2 四种事件模式，各有各的用处
Cordis的事件有四种派发模式，对应不同的场景：
emit模式，发射就忘，纯广播通知，适合记日志这种不影响主流程的活；
waterfall模式，链式传递，能改数据能拦截，适合做过滤器、权限校验；
serial模式，串行挨个执行，适合投票决策类的场景；
parallel模式，并行一起跑，适合群发任务。
5.3 实战：想拦就拦的Agent循环
DSH的Agent循环，就是事件系统最好的例子。
一轮对话拆成好几个步骤，每个关键节点都抛事件，插件想在哪插就在哪插。
比如你想做个敏感词过滤，就监听agent/pre‑step事件，查到敏感词就不调用next，直接短路整个流程。跟Koa的中间件一个道理，灵活得很。
至于什么时候用服务什么时候用事件？记住一句话：稳定能力调用找服务，拦截策略扩展用事件。
6 核心机制五：可配置插件------用配置文件拼乐高
6.1 不用写代码也能定制Agent
前面说的都是写代码做插件，DSH还有更狠的玩法：用配置文件就能组合插件。
一行代码不写，就能定制出完全不一样的Agent。
这套配置体系分四层，从底到上分别是插件包、配置档案补丁、全局补丁、命令行临时覆盖，优先级逐层升高，一层叠一层。
就像叠buff，底层是基础套装，上面每层都能改点东西，最后叠出来你想要的效果。
6.2 连产品形态都是配置出来的
Patch文件就是个YAML，通过行ID定位，想替换某个插件就替换，想新增就新增。
换个自定义大模型适配器、加个审计日志插件，写几行配置就搞定。
DSH内置的四种模式------标准、PTC、极简、创造，本质就是加载了不同的插件集合。
没有什么乱七八糟的if‑else判断模式，切换模式就是换配置文件，换一棵插件树。连产品形态都能靠配置拼出来，这才是真·一切皆插件。
7 这套架构到底香在哪
7.1 零fork就能扩展核心
传统框架改核心行为，得fork仓库、改源码、自己维护后续差异，跟自己养了个孩子似的，操不完的心。
Cordis里？写个插件，提供个新的服务实现，就完事了。
换远程沙箱这种在别的框架里算大工程的需求，在这就是一个插件的事。
7.2 热插拔安全又省心
副作用自动追踪回滚，保证插件插得上、拔得干净。
热重载、动态启停、A/B实验，这些能力都是水到渠成的。改完代码不用重启进程，旧的自动清干净，新的自动加载上，别的插件毫无感知。
7.3 依赖关系自动管理
靠inject声明依赖，框架自动排加载顺序。
不用你手动排序，不用你写判断检查服务有没有就绪。依赖没了插件自动卸载，依赖回来了自动重新加载，全是声明式的，省了一大堆样板代码。
7.4 配置就是产品形态
同一套代码库，靠不同的配置组合，就能变出完全不同的产品形态。
开发工具、CI机器人、基准测试平台，不用维护多个分支，换配置就行。
说白了，现在Agent领域还在疯跑，新模型、新工具、新调度策略天天冒出来。
这时候你死抱着一个固定核心的框架，哪天行业方向变了，你就得跟着大改特改，累都累死。
不如找个Cordis这样的底座，没有特权核心，所有部件都能换、能组合、能热插拔，怎么变都能接得住。
毕竟在快速变化的行业里，能打能抗的从来不是固定的标准答案，而是随时能改的灵活架构。
P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/H1727548