企业官网建设流程全解析

引言：从 Harness 到 Cordis

在 LLM Agent 系统中，模型只提供生成能力，真正决定系统能否稳定运行的，是围绕模型构建的执行框架：它需要管理 Prompt、工具、上下文、策略、评测与运行流程。Deepseek Harness 正是这样一层用于组织、执行和实验的“执行壳”。但当模型、工具与任务不断增多时，简单的拼接方式很快就会遇到复用难、扩展难、回放难的问题。因此，Harness 需要一种更高层的抽象，把各类能力统一定义为可注册、可组合、可运行的对象。这正是 Cordis 元框架要解决的问题。

传统 Agent 框架有什么问题？

下面逐一展开。

问题一：模型调用、工具调用、Prompt 管理混在一起

例如常见代码：

def run_agent(query): prompt = build_prompt(query) response = model.chat(prompt) tool_call = parse_tool(response) result = call_tool(tool_call) return format_result(result)

问题二：组件没有统一抽象

可能每个模块长得不一样：

class Tool: def execute(...) class Model: def chat(...) class Prompt: def render(...) class Evaluator: def score(...)

问题三：流程硬编码

step1() if condition: step2() else: step3() step4()

因此，Deepseek Harness 引入 Cordis。Cordis 的作用不是实现某个具体业务，而是定义一套元规则：什么对象可以被注册，什么对象可以被组合，组合后的对象如何运行，运行过程如何被观测和评测。

从“写 Agent”到“组装 Agent”

Cordis 是什么？

Cordis是《A Programming Paradigm for Spatiotemporal Composability》 的实现，论文指出现代软件越来越需要动态组合（运行时加载/卸载/重配置组件，如 VSCode 插件系统、自我修改的 agent harness），但现状只能靠"重启进程/重启容器"这种粗粒度手段：

Cordis架构的核心思想是把 effect / coeffect 从编译期概念提升为运行时机制，通过以下机制实现：

五大核心概念

下面逐一展开。

Registry 依赖注入

组件用inject数组声明依赖，Registry 保证：apply被执行时，声明的依赖一定已经可用。依赖未就绪时插件停在等待状态，就绪后才运行；依赖消失时插件自动失活。插件作者不需要写任何判空或等待逻辑。

const myPlugin = { inject: ['mcp', 'tools'], // 声明依赖 apply(ctx) { ctx.mcp.excute() } } ctx.plugin(myPlugin) // 交给 Registry 装配

Coeffect 依赖解析

Coeffect是 effect的范畴论对偶概念，来自编程语言理论（Petricek 等，ICALP'13）。

论文 §2.2 定义: While effects model a program's impact on the world, coeffects model the world's constraints on the program. （effects 是"程序对世界的影响"，coeffects 是"世界对程序的约束"。）

经典 coeffect 系统只做编译期静态分析（检查需求是否满足）。Coefffect把它提升为运行时机制：上下文每次变化，都会拿各组件的 coeffect 规格逐一对照，把变化分类为三种通知——

• activating：你要的依赖现在齐了 → 激活你

• deactivating：你依赖的东西没了 → 失活你

• neutral：与你无关

这就是Coeffect，也是空间可组合性的来源：组件只需声明inject，依赖的出现/消失/替换由运行时统一协调，组件之间不需要互相知道对方的存在。

const myPlugin = { inject: ['mcp', 'tools'], // ← 这就是一份 coeffect 规格： // "我需要环境提供 mcp 和 tools" apply(ctx) { ctx.mcp.excute(...) // ← 读取 coeffect 并执行操作 } }

Fiber 生命周期

论文定义：一个组件可以被实例化多次，每次实例化携带自己的生命周期状态。我们把这样一次实例化称为 fiber。

源码里Fiber类注释：Runtime instance of one plugin application

每次ctx.plugin()都把组件实例化为一个 fiber，并伴有如下生命周期：

等待依赖（PENDING）→ 执行apply（LOADING）→ 运行中（ACTIVE）→ 卸载清理（UNLOADING）→ 已回收（DISPOSED）异常落入 FAILED。

状态迁移由 coeffect 通知驱动，apply就是论文里"带逆操作的 effect 函数"。

const fiber = ctx.plugin(myPlugin) // 依赖就绪 → 自动执行 apply // 依赖消失 → 自动卸载、回收全部副作用 await fiber.dispose() // 也可手动卸载

Context 统一上下文

apply(ctx)收到的ctx是组件与环境的唯一交互面：读依赖（ctx.llm）、提供服务、注册事件都发生在它上面。每个 fiber 运行在派生的子上下文里，形成上下文树；属性访问经 Proxy 落入 coeffect 解析，用起来和原生字段无异。

apply(ctx) { ctx.mcp.excute(...) // 属性式读取依赖mcp ctx.set('quota', quota) // 反射式提供服务 const sub = ctx.extend() // 派生子上下文 }

Effect 副作用跟踪

apply里的一切环境变更——ctx.on、ctx.set、ctx.plugin——都被自动跟踪：每个操作登记一个逆操作到所属 fiber 上，卸载时按相反顺序逐个执行，环境完全复原。也可以直接用ctx.effect登记自定义清理。

apply(ctx) { ctx.on('ready', handler) // 卸载时自动取消监听 ctx.effect(() => { const timer = setInterval(tick, 1000) // 正向：注册事件 return () => clearInterval(timer) // 逆操作：登记fiber._disposables }) }

定制个人专属DeepSeek Harness

拆解Deepseek Harness(一)：一切皆可插件 按照上一篇文章指引配置好免费模型，就可以使用创造模式创建个人Agent。

user：帮我创建一个没有tool 工具的agent，需要执行工具调用时，直接输出结构化json

assiant：完成！我已经成功创建了一个没有 tool 工具的 No-Tools Agent

PS.免费模型能力边界——创造模式的工具链对 schema 遵循能力要求很高（严格 oneOf、不可变版本、纯 JS 函数体）。这类任务建议换更强的模型（GLM-5.2、Kimi K3、DeepSeek 旗舰），免费 Flash 模型做简单对话可以，创造模式这种精细活会频繁卡壳。

创建完成后点击新建会话，选择该agent，效果如下：