DeepSeek Harness 深度解析：当 Agent Runtime 成为开源基础设施

小星星_20262026-08-20 14:49

2026 年 8 月，DeepSeek 开源了一个不寻常的项目------不是模型，而是让模型可靠工作的运行时系统。

写在前面

如果你还把 AI Agent 理解为"模型 + 工具调用 + while 循环"，DeepSeek Harness 会刷新你的认知。

这不是又一个 LangChain 式的编排框架。它是一个微内核式的 Agent 操作系统------连 Agent Loop 本身都是一个可热替换的插件。它的野心是回答一个根本性问题：

如何让任何模型在生产环境中成为可靠、可审计、可恢复的 Agent？

本文基于对 DeepSeek Harness v0.1 (Developer Preview, 2026.8.13) 源码和架构文档的深入分析，结合实际上手体验，并与 Claude Code（当前最成熟的闭源 Coding Agent）做工程对比。

一、30 秒理解 DeepSeek Harness

一句话： Profile 和 Bundle 在启动时组装 Cordis 插件树；Cordis 向 Agent Scope 注入 Session、SystemPrompt、LLM、Tools 等服务；Agent Loop 只编排 turn/step；所有模型可见事实写入 Session Log；工具通过受治理流水线调用 capability provider。

如果用传统软件类比：

scss 复制代码 
Linux Kernel  ≈  Cordis (插件生命周期 + 依赖解析 + 上下文传播)
systemd       ≈  Profile/Bundle (启动装配)
procfs        ≈  Session Event Log (可观测的事实源)
syscall       ≈  Capability Seam (统一能力接口)
shell         ≈  Agent Loop (用户意图的执行循环)

二、四块基石：为什么不是"又一个框架"

基石 1：Cordis 插件运行时

Cordis 是 DSH 的骨架。它不是普通的依赖注入容器，而是一个具备时空可组合性的元框架。

核心能力：

typescript 复制代码 
// 伪代码：一个工具插件的生命周期
export default class FileReadPlugin extends Plugin {
  @Inject() fs: FileSystemService      // 声明依赖（由其他插件提供）
  @Inject() permissions: PermissionService

  onLoad(ctx: Context) {
    // 注册能力------effect 被自动跟踪
    ctx.registerTool('file_read', {
      description: 'Read file content',
      schema: { path: { type: 'string' } },
      handler: this.readFile.bind(this)
    })
    // 无需写 onUnload ------ Cordis 自动撤销 registerTool 的 effect
  }

  async readFile(params: { path: string }) {
    await this.permissions.check('fs:read', params.path)
    return this.fs.read(params.path)
  }
}

关键创新------可逆性 (Reversibility)：

每个插件产生的副作用都被跟踪为 Effect。卸载插件时，其所有 effect 被自动清理：

csharp 复制代码 
Plugin Load:
  register tool "file_read"  → tracked effect #1
  add prompt section         → tracked effect #2
  subscribe to event         → tracked effect #3

Plugin Unload (自动):
  dispose effect #3 → unsubscribe event
  dispose effect #2 → remove prompt section
  dispose effect #1 → unregister tool

为什么这很重要：

  • Agent 运行时需要安全热更新------不停机加载新工具或切换模型
  • 如果加载了一个有问题的工具插件，可以安全卸载而不影响其他能力
  • 借鉴 React useEffect cleanup 的思想，但应用到整个 agent runtime 层面

与 Claude Code 的对比：

维度 DeepSeek Harness Claude Code
核心工具 全部是插件，可替换 8 个内置工具不可替换
扩展机制 Plugin tree（无限组合） MCP + Hooks + Skills（分层边缘扩展）
热更新 运行时加载/卸载，effect 自动清理 需重启会话

Claude Code 选择"核心不可替换"是有原因的------8 个核心工具与 System Prompt 深度耦合（17K tokens 的指令针对 Claude 行为特征调优），换一个 Read 工具意味着 prompt 里 300+ 字的指令失效。这是产品确定性 与架构灵活性的经典取舍。

基石 2：Session Event Log------可回放的事实源

DSH 不用 messages[] 数组管理对话历史。它使用 append-only 事件日志作为唯一事实源：

sql 复制代码 
Session Log (append-only):
┌────────────────────────────────────────────┐
│ [T0] turn/start                            │
│ [T1] user/message: "Fix the bug in..."     │
│ [T2] step/start                            │
│ [T3] assistant/message (with tool_calls)   │
│ [T4] tool/call: file_read("/src/main.ts")  │
│ [T5] tool/result: { content: "..." }       │
│ [T6] assistant/message: "Found the issue"  │
│ [T7] tool/call: file_edit(...)             │
│ [T8] tool/result: { success: true }        │
│ [T9] step/end                              │
│ [T10] turn/end                             │
└────────────────────────────────────────────┘
         ↓              ↓             ↓
      Resume         Fork          Replay
      (从中断恢复)   (从决策点分叉)  (精确重放)

这里区分两层：

层次 职责 关键特点
持久事件 (Event Log) 记录发生过的所有耐久事实 Append-only，不可修改
当前 Surface (视图) 模型本轮真正看到的内容 可压缩、replace、shadow

压缩不是删除历史，而是改变视图投影：

typescript 复制代码 
// 压缩前：Surface 包含 [T1..T50] 的完整事件
// 压缩后：Surface 用摘要替换 [T1..T40]，保留 [T41..T50]
// 但 Event Log 中 [T1..T40] 仍然存在，可审计可回放

session.compaction.submit({
  surfaceOp: 'replace',
  range: [T1, T40],
  replacement: summaryMessage
})

实践价值------为什么不只用 messages 数组：

场景 messages 数组 Event Log
进程崩溃后恢复 内存数据丢失 从持久化日志重建
从某个决策点尝试另一条路 无法回到过去 Fork 指定事件点
审计"Agent 为什么做了这个决定" 压缩后信息丢失 原始事件永远可查
多个 UI 同时观察同一会话 各自维护副本 统一事件投影
重放验证 Agent 行为 无法精确重现 确定性 Replay

与 Claude Code 的对比：

Claude Code 也使用 JSONL 保存会话轨迹，支持 Resume 和 Fork。但其设计优先级不同：

  • Claude Code：有损压缩优先保证工作效率（5 层 Compaction Pipeline），接受压缩后无法精确还原
  • DeepSeek Harness：事实完整性优先，Surface 压缩不破坏原始日志

这反映了产品 vs 平台的定位差异：终端用户不需要审计每一步；企业部署需要完整的决策可追溯性。

基石 3：Capability Seam------同一工具，不同世界

这是 DSH 最优雅的设计之一。它把每个能力拆成三个角色：

scss 复制代码 
┌─────────────────────────────────────────────────┐
│  Service Definition (能力接口)                    │
│  • 定义方法签名、参数、返回值、错误契约           │
│  • 不含任何具体实现                              │
└────────────────────┬────────────────────────────┘
                     │
         ┌───────────┼───────────┐
         ↓           ↓           ↓
┌──────────────┐ ┌──────────┐ ┌────────────┐
│ Host Provider│ │ Sandbox  │ │ Remote/E2B │
│ (本地执行)    │ │ Provider │ │ Provider   │
└──────────────┘ └──────────┘ └────────────┘
         ↑           ↑           ↑
         └───────────┼───────────┘
                     │
┌────────────────────┴────────────────────────────┐
│  Consumer (工具/命令/Agent)                       │
│  • 只面向 ctx.fs / ctx.subprocess 能力接口        │
│  • 不知道后端是本地、沙箱还是远程                 │
└─────────────────────────────────────────────────┘

实际效果：

typescript 复制代码 
// 工具代码只写一次，面向能力接口
async function bashTool(params: { command: string }, ctx: Context) {
  // ctx.subprocess 可能是本地进程、bubblewrap 沙箱、或远程 E2B 容器
  // 工具代码完全不需要知道
  const result = await ctx.subprocess.spawn({
    argv: ['bash', '-c', params.command],
    cwd: ctx.agent.cwd,
    timeout: 120_000
  })
  return { stdout: result.stdout, exitCode: result.exitCode }
}

替换执行环境时：

yaml 复制代码 
# 本地开发
providers:
  filesystem: host
  subprocess: host

# 安全部署
providers:
  filesystem: sandbox-landlock
  subprocess: sandbox-bubblewrap

# 云端隔离
providers:
  filesystem: e2b-remote
  subprocess: e2b-remote

工具代码不需要任何修改。

与 Claude Code 的对比：

Claude Code 没有显式的 Capability Seam。它的沙箱通过 macOS Seatbelt 实现，与工具代码耦合更紧。但 Claude Code 也有类似思想：MCP 服务器可以替换工具的后端实现，只是粒度更粗（整个工具级别，而非文件系统/子进程级别）。

基石 4：Agent Loop------稳定但可替换的控制主干

Agent Loop 只做编排，不做实现：

typescript 复制代码 
// Agent Loop 的核心职责（简化）
async function* agentLoop(agent: Agent) {
  while (true) {
    // 1. 从 Inbox 获取输入
    const input = await agent.inbox.take()
    session.append({ type: 'turn/start' })

    while (hasWork) {
      // 2. waterfall: 允许插件修改或拒绝
      const prepared = await emit('agent/pre-step', input)

      // 3. 组装上下文（Session 投影 + SystemPrompt + Tool Schema）
      const context = buildContext(session, systemPrompt, tools)

      // 4. 调用模型（通过 ctx.llm 适配器）
      const response = await ctx.llm.stream(context)

      // 5. 有 Tool Call → 进入 Tool Runtime
      if (response.toolCalls.length > 0) {
        const results = await toolRuntime.execute(response.toolCalls)
        session.append(results)
        continue
      }

      // 6. 无 Tool Call → 检查停止条件
      const shouldStop = await emit('agent/turn-stopping')
      if (shouldStop) break
    }

    session.append({ type: 'turn/end' })
  }
}

关键：Loop 本身是可替换插件。

typescript 复制代码 
// 默认：ReAct 循环
plugins: [{ name: 'react-loop', ... }]

// 替换为：Plan-then-Execute
plugins: [{ name: 'plan-execute-loop', ... }]

// 替换为：Tree-of-Thought
plugins: [{ name: 'tree-of-thought-loop', ... }]

// 甚至：让 Claude Code 整个作为 subagent
plugins: [{ name: 'claude-code-subagent', ... }]

与 Claude Code 的对比：

这是两套系统最本质的哲学分歧：

设计选择 DeepSeek Harness Claude Code
Loop 策略 可替换插件 固定 while-loop
规划方式 Loop 插件决定（ReAct / Plan-Execute / ToT） 模型内在规划（Extended Thinking）
设计信念 "没有一种 loop 策略适合所有场景" "模型是最好的规划器"

Claude Code 的判断是：让模型自己决定下一步比任何确定性规划器都灵活。模型升级后自动获得更好的规划能力，无需改 Harness 代码。这在 Claude Opus 4.6 的能力水平上是合理的。

DSH 的判断是：不同任务适合不同策略------简单 typo fix 用 ReAct 一步搞定，复杂重构需要先计划后执行，探索性 debug 可能需要多路并行。这对构建 Agent 平台（而非单一产品）更有价值。

三、实践：一次工具调用的完整旅程

让我们跟踪一次 file_read("/src/main.ts") 调用，看它如何穿过 DSH 的完整管线：

css 复制代码 
模型输出: tool_use { name: "file_read", input: { path: "/src/main.ts" } }
    │
    ▼
┌─ Step 1: Tool Runtime 入口 ─────────────────────────────┐
│  从 ctx.tools 注册表查找 "file_read"                      │
│  未找到 → 返回 error tool_result，模型获知工具不可用       │
└─────────────────────────────────────────────────────────┘
    │ 找到
    ▼
┌─ Step 2: Schema 校验 ──────────────────────────────────┐
│  tool.inputSchema.safeParse({ path: "/src/main.ts" })   │
│  失败 → 返回 INVALID_ARGS，工具 handler 不会被调用       │
└─────────────────────────────────────────────────────────┘
    │ 通过
    ▼
┌─ Step 3: 审批 (Approval) ──────────────────────────────┐
│  ctx.approval.request("file_read", params)              │
│  • 审批服务不存在 → 默认 DENY (fail-closed)             │
│  • 审批被拒绝 → 返回 denied tool_result                 │
│  • 审批通过 → 继续                                      │
└─────────────────────────────────────────────────────────┘
    │ 批准
    ▼
┌─ Step 4: 单调守卫 (Monotonic Guard) ───────────────────┐
│  检测相同参数的重复调用                                   │
│  第 1 次 → 通过                                         │
│  第 2+ 次 → 注入 reminder，但不硬阻断                    │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─ Step 5: 并发分类 ─────────────────────────────────────┐
│  file_read 声明为 concurrency-safe (纯读取)             │
│  → 进入有界并发池 (max N 并发)                           │
│  file_edit 声明为 exclusive                             │
│  → 形成 barrier，等前面执行完再开始                      │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─ Step 6: 执行 ────────────────────────────────────────┐
│  调用 ctx.fs.read("/src/main.ts")                      │
│  ctx.fs → 当前 Provider 可能是:                         │
│    • HostFS: 直接 Node.js fs.readFile                  │
│    • SandboxFS: 检查路径是否在 workspace 内             │
│    • RemoteFS: 通过 E2B API 读取远程文件                │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─ Step 7: 结果处理 ────────────────────────────────────┐
│  • Output Schema 校验                                  │
│  • 大结果外置（保留摘要 + URI 引用）                     │
│  • 内容脱敏（如果配置了敏感路径规则）                     │
└─────────────────────────────────────────────────────────┘
    │
    ▼
┌─ Step 8: 顺序提交 ────────────────────────────────────┐
│  即使并发执行完成顺序不同，                               │
│  tool_result 按模型原始调用顺序写入 Session               │
│  → 保证回放确定性                                       │
└─────────────────────────────────────────────────────────┘
    │
    ▼
Session Event Log: tool/result { callId, content, ... }
→ 下一个 step 的 deriveMessages() 将包含这个结果

对比 Claude Code 的工具管线：

css 复制代码 
Claude Code 的管线（从历史源码分析）:
  Schema 校验 → 语义校验(路径在工作区内？)
  → PreToolUse Hook → Permission Gate (7 modes + ML classifier)
  → 执行 → PostToolUse Hook → 结果限制大小
  → 配对 tool_result 写回消息

两者的共同点：都不信任模型的工具调用，在执行前设置多层检查。 差异在于 DSH 把每一层都做成了可插拔服务，Claude Code 则把核心检查与特定模型行为深度绑定。

四、实践：沙箱、文件系统与进程树

这是 DSH 设计最精细的部分之一。三个子系统各司其职：

4.1 沙箱：限制进程的文件效果

typescript 复制代码 
// SandboxMode 不是二元开关，而是分级策略
type SandboxMode =
  | 'read-only'           // 只读（浏览代码）
  | 'workspace-write'     // 只能写工作区内（日常开发）
  | 'danger-full-access'  // 完全访问（需显式审批）

关键约束：

  • Linux: bubblewrap 或 Landlock
  • macOS: Seatbelt
  • Windows: 受限 token + ACL
  • 后端不可用时必须 fail-closed（不静默降级为裸执行）

4.2 文件系统：带版本守卫的原子操作

typescript 复制代码 
// 写入前必须先观察（Observation Policy）
const observed = await ctx.fs.read(target)  // 记录版本

// 编辑使用版本守卫，防止并发修改
await ctx.fs.editText(target, {
  versionToken: observed.version,  // 如果文件已被修改，此操作失败
  search: 'old content',
  replace: 'new content'
})

这解决了一个实际问题：Agent 读了文件、思考了很久、再去编辑时，文件可能已经被另一个进程或另一个 Agent 修改了。

4.3 子进程：管理进程树而非单个 PID

typescript 复制代码 
const proc = await ctx.subprocess.spawn({
  argv: ['npm', 'test'],        // 不经过隐式 shell 解析
  cwd: '/workspace/project',
  timeout: 120_000,
  stdio: {
    stdout: 'pipe',             // 有界收集，超限保留 tail
    stderr: 'pipe'
  },
  gracePeriod: 5_000            // SIGTERM → 5s → SIGKILL
})
// 终止是整棵进程树级别

关键设计：Filesystem 与 Subprocess Provider 必须指向同一个 execution world。 Bash、PTY、LSP 和文件工具看到的是同一份工作区。远程化时应成对替换 Provider。

五、实践：上下文压缩------不是删除，是改变视图

DSH 的压缩策略是可选 Capability，不是硬编码在循环里的分支：

typescript 复制代码 
// 触发时机
ctx.on('agent/pre-step', async (input, next) => {
  if (tokenPressure > threshold) {
    await ctx.compaction.run()  // 在 step 之间执行，不破坏执行中的状态
  }
  return next(input)
})

压缩流程：

bash 复制代码 
1. 预裁剪 (无需模型调用)
   对过大的 tool_result 保留头部 + 中部标记 + 尾部
   ↓
2. 范围选择
   选择 Surface 中可压缩的区间
   边界必须保持 tool_call / tool_result 配对完整
   ↓
3. 模型摘要
   用摘要模型对选定区间生成概要
   ↓
4. Surface Replace
   摘要作为新 user/message 通过 surfaceOp: replace 覆盖可见区间
   原始事件仍在 Event Log 中
   ↓
5. 故障保护
   compaction/start 最先写、compaction/end 最后写
   崩溃会留下可检测的孤儿锁，不会伪装成成功

与 Claude Code 的 5 层 Pipeline 对比：

层次 Claude Code DeepSeek Harness
源头限制 单次 tool 返回 > 50K chars → 摘要 Tool Result Pruner 确定性裁剪
旧结果回收 按 "compactable" 类别优先压缩 Surface replace 选定区间
对话摘要 AI 摘要替代旧轮次 同，用摘要模型
隔离 Sub-agent 只返回结论 Subagent 独立 Session
触发 ~80% usage 自动触发 agent/pre-step 检测压力
原始数据 压缩后不可精确还原 Event Log 保留原始事件

六、实践：多模型协同------DSH 独有的能力

这是 DSH 相比 Claude Code 最大的架构优势之一：

yaml 复制代码 
# DSH 支持在同一会话中使用多个模型
models:
  planner:
    provider: deepseek
    model: deepseek-v4-pro
    role: 规划和决策（强推理）

  executor:
    provider: openai-compatible
    model: deepseek-v4-flash
    role: 执行 grunt work（便宜快速）

  reviewer:
    provider: anthropic
    model: claude-opus
    role: 代码审查（需要深度理解）

实际场景：

  • 用便宜的 Flash 模型做大量代码搜索和文件读取
  • 用 Pro 模型做关键的架构决策和复杂编辑
  • 用 Claude 做最终的代码审查
  • DeepSeek V4 的 prefix caching 让同 session 内重复前缀极便宜

Claude Code 的限制：

  • 锁定 Claude 模型家族（Opus/Sonnet/Haiku）
  • System Prompt 与 Claude 行为特征深度耦合（17K tokens 调优）
  • 换模型 → prompt 里的微妙指令失效
  • Token 估算依赖 Claude tokenizer
  • 商业模型：harness 免费，模型 API 收费

七、架构全景对比：DSH vs Claude Code

设计维度 DeepSeek Harness Claude Code
产品定位 Agent 运行时平台/框架 终端用户编码产品
开源策略 MIT 全开源 闭源（社区逆向分析）
核心理念 "Everything is a Plugin" "Thin Brain, Thick OS"
模型策略 模型无关，多模型协同 锁定 Claude，深度调优
Loop 策略 可替换插件 固定 while-loop
安全模型 Capability-based（编程式） Deny-first 7-mode（交互式）
状态管理 Event Sourcing（完整可重放） 有损压缩（优先有效工作）
扩展性 一切可替换（含核心循环） 核心不可替换，边缘可扩展
可观测性 原生 Session 重放 + Trajectory View 会话历史 + 终端输出
成熟度 Developer Preview (v0.1) 生产级（迭代 1.5+ 年）
CLI dsh claude

八、DSH 的安全模型：Capability-Based Security

与 Claude Code 的交互式权限不同，DSH 采用编程式的能力安全模型：

typescript 复制代码 
// 插件只拥有被显式授予的 capabilities
class MyToolPlugin extends Plugin {
  // 声明需要的能力------运行时只授予这些
  static capabilities = [
    'fs:read(/workspace/*)',
    'shell:exec(git, npm, node)',
    // 没有声明 fs:write → 即使在高权限进程中也无法写文件
  ]
}

与 Claude Code 7 种权限模式的对比：

sql 复制代码 
Claude Code (面向终端用户):
  Ask Every Time → Allow Read Only → Allow Edit → Allow All
  Auto Mode (ML 分类器判断风险)
  → 用户坐在终端前实时控制

DeepSeek Harness (面向开发者/部署):
  能力声明 → 运行时授权 → 审批服务 → 沙箱强制
  → 编程式配置，适合服务端部署

两者设计的受众不同：

  • Claude Code 面向坐在终端前的人类开发者------需要实时控制感
  • DSH 面向在生产中运行 Agent 的团队------需要可编程的策略配置

九、适用判断：什么时候选哪个

选 DeepSeek Harness 的场景

  • 构建自己的 Agent 产品（需要运行时平台）
  • 生产服务端部署（需要审计链和可恢复性）
  • 多模型降本（便宜模型做搜索，贵模型做决策）
  • 需要完整重放能力（合规、调试）
  • 要在同一 runtime 上运行不同类型的 Agent
  • 团队有能力消化 Cordis/Fiber/Effect 的学习曲线

选 Claude Code 的场景

  • 个人日常编码提效（零配置即用）
  • 追求单一场景极致体验
  • 不需要（或不想管）运行时基础设施
  • 信任 Claude 模型的规划能力
  • 需要成熟的、经过大规模验证的产品

两者结合

yaml 复制代码 
# 完全可以把 Claude Code 作为 DSH 的一个 subagent provider
subagent_providers:
  - type: claude-code
    role: coding-expert
    budget: 50_000_tokens

十、DSH 的局限性------保持清醒

不要被架构优雅迷惑，DSH 当前存在明确的边界：

  1. Developer Preview：API、配置格式和包边界可能继续变化，不宜直接用于生产
  2. 学习成本高：Cordis + Fiber + Effect + Scope + Waterfall + Capability Seam，新手不友好
  3. 性能证据缺口：官方没有发布"Harness 使模型基准提升 X%"的数据
  4. 安全保证不等价：Landlock / bubblewrap / Seatbelt 的隔离强度不同，不能假设"接口统一 = 安全等价"
  5. Vendor 分叉：Cordis 被 vendored 并大量修改，升级成本高
  6. 生态尚未成熟：插件市场和社区贡献处于早期

十一、设计原则提炼------可迁移的工程认知

无论你是否采用 DSH，以下原则值得带走：

原则 DSH 体现 Claude Code 体现 通用意义
注册即 Effect 插件卸载自动清理所有副作用 --- 长运行系统必须有资源所有权
模型可见 = 已持久化 Event Log 先于模型请求 JSONL 保存完整轨迹 不靠内存保状态
概率指导，确定性强制 模型选工具，审批/沙箱强制执行 Prompt 建议，Permission Gate 强制 关键边界不靠自然语言
执行与结果分离 并发执行，顺序提交 流式工具可提前启动 吞吐与确定性可以兼得
能力接口与后端解耦 Definition + Provider + Consumer MCP 协议 换后端不改工具代码
安全 fail-closed 审批缺失 → 默认拒绝 未知工具 → 无法执行 宁可拒绝也不静默降级

结语：Agent 工程的下一个十年

DeepSeek Harness 的发布标志着一个转折点：Agent 竞争从"谁的模型更强"扩展到了"谁的运行时基础设施更可靠"。

模型能力在快速趋同------DeepSeek V4 已经逼近 Claude 水平。但生产级的 Agent Runtime 有巨大的工程壁垒：状态管理、安全隔离、热更新、可审计性、多模型调度。这些不是几个 prompt 能解决的。

DeepSeek 的赌注是：开源 Harness 形成生态 → 更多开发者用 DeepSeek 模型构建 Agent → 模型 API 收入增长。 类比 Linux：内核不赚钱，围绕它的生态价值万亿。

Claude Code 的赌注是：模型持续领先 → 深度耦合的 Harness 提供最佳体验 → 锁定用户和收入。 类比 iPhone：不需要开放硬件接口，靠体验赢。

两种路径都有成功的可能。对于工程师和架构师来说，真正重要的是理解底层设计取舍------不管最终选择哪套系统，这些认知都是可迁移的。

分析基线：DeepSeek Harness v0.1 Developer Preview (2026.8.13)，Claude Code 生产版 (持续迭代至 2026.8)。

参考资料：

相关推荐
小星星_20261 小时前
AI Coding Agent 的真正战场：Harness 工程深度解析
ai编程
极客小俊1 小时前
Windows安装部署Claude Code+CC‑Switch+Agnes AI 保姆级教程
agent·ai编程·claude
console.log('npc')2 小时前
DeepSeek Harness 使用教程
大模型·ai编程·deepseek·harness
用户125758524362 小时前
对象存储 URL 为什么别到处拼：后台附件预览要验这一层
后端·go·ai编程
枝恩2 小时前
Skill 学习指南：给 AI Agent 装一本“专项操作手册“
ai编程
Java小白笔记4 小时前
Windows系统免软件命令激活
java·网络·人工智能·windows·ai·ai编程
霸道流氓气质4 小时前
Java开发者AI编程常用MCP、Skills、Rules全景汇总
java·开发语言·ai编程
JavaDog程序狗4 小时前
【教程】WorkBuddy+Obsidian打造自动运转的个人知识库
ai编程
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新042026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？05历年考研数学一、数学二、数学三真题试卷及答案PDF06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08VSCode+CodeX扩展，无法启动092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片10如何新建文件夹？ 电脑新建文件夹的4种方法