Corids框架基础——“一切皆插件”理解DeepSeek harness的地基cord插框架本章目标什么是插件化架构为什么是Agent框架要这么设计5个核心设计思想先问一个问题什么是 Agent想象你要开一家AI 公司这家公司的目标是接收客户任务 → 思考 → 调用工具 → 返回结果。客户说“帮我查一下天气然后写一首关于天气的诗”Agent 要做的事理解任务需要 LLM 大脑调用查天气工具拿到天气数据调用写诗能力返回结果问题来了如果每做一个新 Agent你都要从零写怎么调工具、“怎么管对话”、“怎么换模型”……太累了Cordis 就是解决这个的——它是一套公司管理框架让你像搭积木一样组装 Agent。Cordis 概念公司类比具体例子插件 (Plugin)一个员工/部门“工具部”、“模型部”、“安全部”上下文 (Context)公司通讯录/公告板每个员工通过通讯录找到其他部门服务 (Service)部门提供的能力“工具部”提供ctx.tools各种工具事件 (Event)公司广播/邮件“有新任务了”、“工具调用完毕”依赖注入 (inject)入职前提“安全部”成立的前提是“工具部”已经存在效果 (Effect)入职/离职手续员工离职时自动交接工作、归还工牌核心概念Cordis的五大思想Cordis 是整个 dsh 框架的底层哲学。想象它是一个**“插件操作系统”**——每个功能都是一个可插拔的模块。思想一插件 员工插件是一个实现服务的对象在coredis中插件有三种形态。// 形态 1函数插件最常用exportconstnamemy-plugin// 可选用于诊断export functionapply(ctx:Context){// 在这里注册你的贡献}// 形态 2对象插件exportconstmyPlugin{name:my-object-plugin,apply(ctx:Context){/* ... */}}// 形态 3类插件Service 子类classMyServiceextendsService{constructor(ctx:Context){super(ctx,myService)// 注册服务名}}一句话理解插件就是一个员工入职时告诉公司我能干什么。思想二Context 公司通讯录Context是所有服务的容器插件通过Context找到它需要的服务而不是直接import具体实现。没有Cordis的情况混乱我要用搜索功能→ 你newSearchTool()→ 你newDeepSeekLLM()→ 你newFileSaver()每个地方都要自己找具体的人换个人就要改代码 有Cordis的情况有序我要用搜索功能→ ctx.tools.execute(search,...)你不管具体是谁在做通讯录(ctx)帮你找到一句话Context 让你找人办事不用知道具体是谁只认岗位不认人。思想三依赖注入 入职前提插件通过inject字段声明它需要什么服务coredis会等所有依赖就绪后才加载插件场景你想成立安全审计部但它必须等工具部成立后才能工作 因为安全部要审计工具调用 没有依赖注入 你手动安排先加载工具部 → 再加载安全部 万一顺序错了安全部找不到工具部崩溃 有依赖注入// 安全部的定义exportconstinject[tools]// 我需要 tools 部先成立Cordis自动处理1.看到安全部需要 tools2.先加载 tools3.tools 就绪后再加载安全部一句话你只声明我需要谁框架自动安排顺序。思想四事件 公司广播事件是插件间松耦合通信的方式Core Redis有5种调度模式。emit——广播通知// 服务方发射事件classStatsServiceextendsService{bump(name:string){constnext(this.counts.get(name)??0)1this.counts.set(name,next)this.ctx.emit(stats/report,name,next)// 广播}}// 消费方监听事件export functionapply(ctx:Context){ctx.on(stats/report,(name,count){console.log(${name}-${count})})}一句话事件 “我做了件事谁关心谁听着”发布者不知道也不关心谁在听思想五效果 自动离职交接Cordis最精妙的设计场景一个插件被卸载比如配置改了、热更新 没有效果管理 插件卸载了但它注册的监听器还在 → 内存泄漏 它启动的定时器还在 → 定时器报错 它注册的 service 还在 → 别人调用时崩溃 有效管理Cordis export functionapply(ctx){// 注册监听器 → 卸载时自动移除ctx.on(event,handler)// 启动定时器 → 卸载时自动清理ctx.effect((){consttimersetInterval(...)return()clearInterval(timer)// ← 这个函数在卸载时自动执行})}Fiber状态机插件的生命周期PENDING ──→ LOADING ──→ ACTIVE ──→ UNLOADING ──→ DISPOSED│└──→ FAILEDPENDING等待依赖服务就绪LOADING / ACTIVEapply() 执行中 / 已完成FAILED加载失败UNLOADING / DISPOSED清理中 / 已清理深入理解Waterfall 审批流程Waterfall 是 dsh 中使用最频繁的模式理解它就理解了 Agent 的拦截链这是最难理解的用公司审批类比场景员工要调用一个危险工具比如删除文件需要审批 直接调用 tool.delete(file)→ 直接执行没有拦截Waterfall审批链 员工发起请求 → 经过层层审批 → 最终执行或拒绝 调用 ctx.waterfall(approval/request, 删除文件)│ ▼ ┌─────────────────────────────┐ │ 第1层日志记录员 │ │有人要删除文件我先记一笔│ │ 调用next()→ 继续往下 │ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ 第2层安全策略员 │ │删除文件让我看看规则...│ │ 规则说不能删除系统文件 │ │ 直接返回拒绝✂️ │ ← 不调用next()链断了 └─────────────────────────────┘ │ ▼(返回值往上走)┌─────────────────────────────┐ │ 第1层收到拒绝│ │哦被拒绝了我也返回拒绝│ └─────────────────────────────┘ │ ▼ 最终结果拒绝执行执行流程调用 ctx.waterfall(‘approval/request’, ‘rm -rf /’)│▼┌─────────────────────────┐│ 监听器 1 (日志记录) ││ 调用 next() ──────────┼──┐└─────────────────────────┘ │▼┌─────────────────────────┐│ 监听器 2 (安全策略) ││ 发现是危险工具 ││ 直接返回 false ✂️ │ ← 短路不调用 next()└─────────────────────────┘│▼ (返回值上浮)┌─────────────────────────┐│ 监听器 1 收到 false ││ 记录日志返回 false │└─────────────────────────┘│▼最终结果: false (拒绝执行)总结概念一句话解释类比Context插件之间互相找到对方的渠道公司通讯录Service一个插件提供的能力部门如工具部Event (emit)广播通知谁监听谁收到公司大喇叭Waterfall层层处理可以中途拦截审批流程Effect注册的东西卸载时自动清理离职交接Cordis 的五大思想插件 员工 → 每个功能是一个独立模块Context 通讯录 → 通过它找到其他服务依赖注入 入职前提 → 声明需要什么框架自动安排事件 广播 → 松耦合通信效果 自动清理 → 生命周期自动管理Cordis 有五个核心机制插件即服务每个插件是一个函数或类通过 apply(ctx) 向系统注册自己的能力。上下文定位插件之间不直接 import而是通过 ctx 找到需要的服务。比如 ctx.tools 找到工具注册器。这样消费者和提供者完全解耦——换实现不改代码。依赖注入插件用 inject 声明需要什么服务框架自动按依赖顺序加载。配置文件里的顺序无所谓。类型化事件插件间通过事件通信。ctx.emit 广播通知谁监听谁收到。发布者不知道谁在听新增监听者不改发布者代码。可逆效果所有注册都是’效果’插件卸载时自动清理——监听器移除、定时器停止不会内存泄漏。总结一句话概括Cordis 是 dsh 的底层框架通过插件化 事件驱动 依赖注入实现一切皆插件、一切可替换。核心知识点五大思想| 思想 | 一句话 | 类比 ||—|—|—||插件即服务|apply(ctx)注册能力 | 员工入职报到 ||上下文定位|ctx找服务不直接import| 公司通讯录 ||依赖注入|inject声明依赖框架负责排序 | 入职前提 ||类型化事件|emit广播 /waterfall审批 | 公司大喇叭 / 审批流程 ||可逆效果| 注册的东西卸载时自动清理 | 离职交接 |两种关键事件模式emit广播大喇叭通知谁监听谁收到发布者不知道谁在听waterfall审批链层层处理next()放行不调用next()拦截3. Fiber 生命周期PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED面试怎么答“Cordis 的核心是插件化架构。插件通过 apply(ctx) 向系统注册能力通过 ctx 查找其他服务解耦通过 inject 声明依赖框架自动排序。通信靠事件——emit 做广播通知waterfall 做可拦截的审批链。所有注册都是’效果’卸载时自动清理支持热加载。”一页速记五大思想插件即服务 / 上下文定位 / 依赖注入 / 类型化事件 / 可逆效果事件模式emit(广播) / waterfall(审批链, next()放行, 不调用拦截)生命周期PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED效果管理ctx.effect(() { … return 清理函数 }) Deepseek harness 底层的Cordis就像一个公司？
Corids框架基础——“一切皆插件”理解DeepSeek harness的地基cord插框架本章目标什么是插件化架构为什么是Agent框架要这么设计5个核心设计思想先问一个问题什么是 Agent想象你要开一家AI 公司这家公司的目标是接收客户任务 → 思考 → 调用工具 → 返回结果。客户说“帮我查一下天气然后写一首关于天气的诗”Agent 要做的事理解任务需要 LLM 大脑调用查天气工具拿到天气数据调用写诗能力返回结果问题来了如果每做一个新 Agent你都要从零写怎么调工具、“怎么管对话”、“怎么换模型”……太累了Cordis 就是解决这个的——它是一套公司管理框架让你像搭积木一样组装 Agent。Cordis 概念公司类比具体例子插件 (Plugin)一个员工/部门“工具部”、“模型部”、“安全部”上下文 (Context)公司通讯录/公告板每个员工通过通讯录找到其他部门服务 (Service)部门提供的能力“工具部”提供ctx.tools各种工具事件 (Event)公司广播/邮件“有新任务了”、“工具调用完毕”依赖注入 (inject)入职前提“安全部”成立的前提是“工具部”已经存在效果 (Effect)入职/离职手续员工离职时自动交接工作、归还工牌核心概念Cordis的五大思想Cordis 是整个 dsh 框架的底层哲学。想象它是一个**“插件操作系统”**——每个功能都是一个可插拔的模块。思想一插件 员工插件是一个实现服务的对象在coredis中插件有三种形态。// 形态 1函数插件最常用exportconstnamemy-plugin// 可选用于诊断export functionapply(ctx:Context){// 在这里注册你的贡献}// 形态 2对象插件exportconstmyPlugin{name:my-object-plugin,apply(ctx:Context){/* ... */}}// 形态 3类插件Service 子类classMyServiceextendsService{constructor(ctx:Context){super(ctx,myService)// 注册服务名}}一句话理解插件就是一个员工入职时告诉公司我能干什么。思想二Context 公司通讯录Context是所有服务的容器插件通过Context找到它需要的服务而不是直接import具体实现。没有Cordis的情况混乱我要用搜索功能→ 你newSearchTool()→ 你newDeepSeekLLM()→ 你newFileSaver()每个地方都要自己找具体的人换个人就要改代码 有Cordis的情况有序我要用搜索功能→ ctx.tools.execute(search,...)你不管具体是谁在做通讯录(ctx)帮你找到一句话Context 让你找人办事不用知道具体是谁只认岗位不认人。思想三依赖注入 入职前提插件通过inject字段声明它需要什么服务coredis会等所有依赖就绪后才加载插件场景你想成立安全审计部但它必须等工具部成立后才能工作 因为安全部要审计工具调用 没有依赖注入 你手动安排先加载工具部 → 再加载安全部 万一顺序错了安全部找不到工具部崩溃 有依赖注入// 安全部的定义exportconstinject[tools]// 我需要 tools 部先成立Cordis自动处理1.看到安全部需要 tools2.先加载 tools3.tools 就绪后再加载安全部一句话你只声明我需要谁框架自动安排顺序。思想四事件 公司广播事件是插件间松耦合通信的方式Core Redis有5种调度模式。emit——广播通知// 服务方发射事件classStatsServiceextendsService{bump(name:string){constnext(this.counts.get(name)??0)1this.counts.set(name,next)this.ctx.emit(stats/report,name,next)// 广播}}// 消费方监听事件export functionapply(ctx:Context){ctx.on(stats/report,(name,count){console.log(${name}-${count})})}一句话事件 “我做了件事谁关心谁听着”发布者不知道也不关心谁在听思想五效果 自动离职交接Cordis最精妙的设计场景一个插件被卸载比如配置改了、热更新 没有效果管理 插件卸载了但它注册的监听器还在 → 内存泄漏 它启动的定时器还在 → 定时器报错 它注册的 service 还在 → 别人调用时崩溃 有效管理Cordis export functionapply(ctx){// 注册监听器 → 卸载时自动移除ctx.on(event,handler)// 启动定时器 → 卸载时自动清理ctx.effect((){consttimersetInterval(...)return()clearInterval(timer)// ← 这个函数在卸载时自动执行})}Fiber状态机插件的生命周期PENDING ──→ LOADING ──→ ACTIVE ──→ UNLOADING ──→ DISPOSED│└──→ FAILEDPENDING等待依赖服务就绪LOADING / ACTIVEapply() 执行中 / 已完成FAILED加载失败UNLOADING / DISPOSED清理中 / 已清理深入理解Waterfall 审批流程Waterfall 是 dsh 中使用最频繁的模式理解它就理解了 Agent 的拦截链这是最难理解的用公司审批类比场景员工要调用一个危险工具比如删除文件需要审批 直接调用 tool.delete(file)→ 直接执行没有拦截Waterfall审批链 员工发起请求 → 经过层层审批 → 最终执行或拒绝 调用 ctx.waterfall(approval/request, 删除文件)│ ▼ ┌─────────────────────────────┐ │ 第1层日志记录员 │ │有人要删除文件我先记一笔│ │ 调用next()→ 继续往下 │ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ 第2层安全策略员 │ │删除文件让我看看规则...│ │ 规则说不能删除系统文件 │ │ 直接返回拒绝✂️ │ ← 不调用next()链断了 └─────────────────────────────┘ │ ▼(返回值往上走)┌─────────────────────────────┐ │ 第1层收到拒绝│ │哦被拒绝了我也返回拒绝│ └─────────────────────────────┘ │ ▼ 最终结果拒绝执行执行流程调用 ctx.waterfall(‘approval/request’, ‘rm -rf /’)│▼┌─────────────────────────┐│ 监听器 1 (日志记录) ││ 调用 next() ──────────┼──┐└─────────────────────────┘ │▼┌─────────────────────────┐│ 监听器 2 (安全策略) ││ 发现是危险工具 ││ 直接返回 false ✂️ │ ← 短路不调用 next()└─────────────────────────┘│▼ (返回值上浮)┌─────────────────────────┐│ 监听器 1 收到 false ││ 记录日志返回 false │└─────────────────────────┘│▼最终结果: false (拒绝执行)总结概念一句话解释类比Context插件之间互相找到对方的渠道公司通讯录Service一个插件提供的能力部门如工具部Event (emit)广播通知谁监听谁收到公司大喇叭Waterfall层层处理可以中途拦截审批流程Effect注册的东西卸载时自动清理离职交接Cordis 的五大思想插件 员工 → 每个功能是一个独立模块Context 通讯录 → 通过它找到其他服务依赖注入 入职前提 → 声明需要什么框架自动安排事件 广播 → 松耦合通信效果 自动清理 → 生命周期自动管理Cordis 有五个核心机制插件即服务每个插件是一个函数或类通过 apply(ctx) 向系统注册自己的能力。上下文定位插件之间不直接 import而是通过 ctx 找到需要的服务。比如 ctx.tools 找到工具注册器。这样消费者和提供者完全解耦——换实现不改代码。依赖注入插件用 inject 声明需要什么服务框架自动按依赖顺序加载。配置文件里的顺序无所谓。类型化事件插件间通过事件通信。ctx.emit 广播通知谁监听谁收到。发布者不知道谁在听新增监听者不改发布者代码。可逆效果所有注册都是’效果’插件卸载时自动清理——监听器移除、定时器停止不会内存泄漏。总结一句话概括Cordis 是 dsh 的底层框架通过插件化 事件驱动 依赖注入实现一切皆插件、一切可替换。核心知识点五大思想| 思想 | 一句话 | 类比 ||—|—|—||插件即服务|apply(ctx)注册能力 | 员工入职报到 ||上下文定位|ctx找服务不直接import| 公司通讯录 ||依赖注入|inject声明依赖框架负责排序 | 入职前提 ||类型化事件|emit广播 /waterfall审批 | 公司大喇叭 / 审批流程 ||可逆效果| 注册的东西卸载时自动清理 | 离职交接 |两种关键事件模式emit广播大喇叭通知谁监听谁收到发布者不知道谁在听waterfall审批链层层处理next()放行不调用next()拦截3. Fiber 生命周期PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED面试怎么答“Cordis 的核心是插件化架构。插件通过 apply(ctx) 向系统注册能力通过 ctx 查找其他服务解耦通过 inject 声明依赖框架自动排序。通信靠事件——emit 做广播通知waterfall 做可拦截的审批链。所有注册都是’效果’卸载时自动清理支持热加载。”一页速记五大思想插件即服务 / 上下文定位 / 依赖注入 / 类型化事件 / 可逆效果事件模式emit(广播) / waterfall(审批链, next()放行, 不调用拦截)生命周期PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED效果管理ctx.effect(() { … return 清理函数 })