@botbotgo/agent-harness 0.0.237 → 0.0.239

package/README.md

@@ -135,7 +135,7 @@ Additional docs:
 - **Easy to start:** `createAgentHarness` → `request` → `stop`, plus inspection helpers such as `subscribe`, `listSessions`, `listApprovals`, and `resolveApproval`.
 - **Configure:** routing, models, tools, stores, backends, MCP, recovery, and maintenance in declarative workspace YAML (see [Quick Start](#readme-en-quickstart) and [How To Configure](#readme-en-config)).
 - **Extend:** drop `tool({...})` modules and SKILL trees under `resources/`, wire shared tools and MCP in catalogs, and let agents whitelist what they use.
-- **Built into the runtime:** persisted `requests`, `sessions`, `approvals`, and `events`; recovery and queueing; streaming listeners; MCP in/out; LangChain v1 and DeepAgents adapters—so you do not rebuild that layer per app.
+- **Built into the runtime:** persisted `requests`, `sessions`, `approvals`, and `events`; recovery and queueing; streaming listeners; MCP in/out; and backend adapters—so you do not rebuild that layer per app.
 
 <a id="readme-en-runtime-glance"></a>
 
@@ -205,17 +205,17 @@ In concrete terms:
 
 `@botbotgo/agent-harness` is a workspace-shaped application runtime for real multi-agent products.
 
-It is not a new agent framework. It is the runtime layer around LangChain v1 and DeepAgents that turns one workspace into one operable application runtime.
+It is not a new agent framework. It is the runtime layer around your existing execution stack that turns one workspace into one operable application runtime.
 
 The positioning is simple:
 
 - Codex, Claude Code, and Cursor are products for people using agents
-- LangChain v1 and DeepAgents are frameworks for defining agent execution semantics
+- execution frameworks define agent execution semantics
 - `agent-harness` is the runtime product layer for operating, recovering, approving, and governing multi-agent applications
 
 The product boundary is strict:
 
-- LangChain v1 and DeepAgents own agent execution semantics
+- execution backends own agent execution semantics
 - application-level orchestration and lifecycle management stays in the harness
 
 That means:
@@ -229,7 +229,7 @@ The runtime provides:
 
 - `createAgentHarness(workspaceRoot)`, `request(...)`, `memorize(...)`, `recall(...)`, `listMemories(...)`, `updateMemory(...)`, `removeMemory(...)`, `resolveApproval(...)`, `subscribe(...)`, inspection methods, and `stop(...)`
 - YAML-defined workspace assembly for routing, models, tools, stores, backends, MCP, recovery, and maintenance
-- backend-adapted execution with current LangChain v1 and DeepAgents adapters
+- backend-adapted execution behind the runtime contract
 - local `resources/tools/` `tool({...})` modules and `resources/skills/` discovery
 - persisted sessions, requests, approvals, events, queue state, and recovery metadata
 
@@ -246,7 +246,7 @@ The default workspace configuration shipped with the package is deliberately ful
 
 The default rule is:
 
-- if LangChain v1 or DeepAgents already has the feature, map it in YAML and adapt it internally
+- if the execution backend already has the feature, map it in YAML and adapt it internally
 - do not add a new public runtime API unless the problem is truly runtime-owned
 
 Start with these user-facing docs:
@@ -317,7 +317,7 @@ Do not reach for it when:
 
 - you only need a single short-lived agent call with no approvals, no persistence, and no operational control surface
 - you are looking for a workflow builder or low-code automation canvas
-- you want to replace LangChain v1 or DeepAgents execution semantics rather than operate around them
+- you want to replace the execution backend's semantics rather than operate around them
 
 <a id="readme-en-quickstart"></a>
 
@@ -397,7 +397,7 @@ If you want the shortest possible mental model:
 - Workspace runtime for multi-agent applications
 - Small public runtime contract
 - YAML-defined host routing and runtime policy
-- LangChain v1 and DeepAgents backend adaptation
+- Backend adaptation behind one runtime contract
 - Auto-discovered local `tool({...})` tools and SKILL packages
 - provider-native tools, MCP tools, and workspace-local tool modules
 - persisted sessions, requests, approvals, lifecycle events, and queued requests
@@ -731,9 +731,9 @@ At the moment, the most stable path for complex production-style runs is `backen
 
 Current temporary limits on the `backend: langchain-v1` path are:
 
-- approval-gated side-effect tools are less reliable than the DeepAgents path under real remote models
+- approval-gated side-effect tools are less reliable on the lighter direct-response path under real remote models
 - long multi-agent or orchestration-heavy flows are not the recommended default path
-- the package now treats DeepAgents as the default execution path for complex runtime coverage, and LangChain v1 should be selected explicitly when a workspace truly wants that behavior
+- the package now treats the planner-first backend as the default execution path for complex runtime coverage, and the lighter direct-response backend should be selected explicitly when a workspace truly wants that behavior
 
 Practical guidance:
 
@@ -856,7 +856,7 @@ Keep bootstrap context in `config/agent-context.md`. Keep resumable execution st
 
 ### `config/catalogs/backends.yaml`
 
-Use reusable DeepAgents backend presets so filesystem and `/memories/*` topology stays in YAML:
+Use reusable backend presets so filesystem and `/memories/*` topology stays in YAML:
 
 ```yaml
 apiVersion: agent-harness/v1alpha1
@@ -988,11 +988,11 @@ For backend-specific options, prefer the upstream concept directly inside `spec.
 - public runtime contract stays generic and small
 - application-level orchestration and lifecycle management stays in the harness
 - the external protocol boundary should strictly conform to `deepagents-acp` instead of a parallel harness-only protocol
-- upstream LangChain v1 and DeepAgents concepts should be expressed as directly as possible in YAML
+- upstream execution-backend concepts should be expressed as directly as possible in YAML
 - when a feature can be expressed in YAML, prefer YAML over expanding the public API
 - recovery, approvals, threads, runs, and events are runtime concepts, not backend escape hatches
 - application task centers should be built on the existing store plus runtime ids instead of expanding the public runtime contract
-- new LangChain v1 or DeepAgents config should land in YAML mapping and tests before adding public runtime APIs
+- new backend-specific config should land in YAML mapping and tests before adding public runtime APIs
 
 In short, the product model stays stable while the execution semantics remain upstream-owned.
 

package/README.zh.md

@@ -131,7 +131,7 @@ try {
 - **容易上手：** `createAgentHarness` → `request` → `stop`，以及 `subscribe`、`listSessions`、`listApprovals`、`resolveApproval` 等查询与控制能力。
 - **配置：** 路由、模型、工具、存储、后端、MCP、恢复与维护写在声明式工作区 YAML 里（见[快速开始](#readme-zh-quickstart)与[如何配置](#readme-zh-config)）。
 - **扩展：** 在 `resources/` 下放置 `tool({...})` 模块与 SKILL 包；共享工具与 MCP 写在 `config/catalogs/` 等 YAML 目录里，各 agent 再按名称白名单引用。
-- **内建运行时：** 持久化 `requests`、`sessions`、`approvals` 与 `events`；恢复与排队；流式监听；MCP 接入与对外暴露；LangChain v1 与 DeepAgents 适配——避免每个应用重复造这一层。
+- **内建运行时：** 持久化 `requests`、`sessions`、`approvals` 与 `events`；恢复与排队；流式监听；MCP 接入与对外暴露；以及后端适配——避免每个应用重复造这一层。
 
 <a id="readme-zh-runtime-glance"></a>
 
@@ -201,17 +201,17 @@ AI 让 agent 逻辑、工具调用和工作流代码更容易生成，真正更
 
 `@botbotgo/agent-harness` 是面向真实多 agent 产品的、工作区形态的应用运行时。
 
-它不是又一个 agent 框架，而是围绕 LangChain v1 与 DeepAgents 的运行时层：把一个工作区变成一套可运维的应用运行时。
+它不是又一个 agent 框架，而是围绕现有执行栈的运行时层：把一个工作区变成一套可运维的应用运行时。
 
 产品定位可以概括为：
 
 - Codex、Claude Code、Cursor 是「人用 agent」的产品
-- LangChain v1 与 DeepAgents 是定义 agent 执行语义的框架
+- 执行框架负责定义 agent 执行语义
 - `agent-harness` 是负责运维、恢复、审批与治理多 agent 应用的运行时产品层
 
 产品边界是清晰的：
 
-- LangChain v1 与 DeepAgents 拥有 agent 执行语义
+- 执行后端拥有 agent 执行语义
 - 应用级编排与生命周期管理留在 harness 中
 
 因此：
@@ -225,7 +225,7 @@ AI 让 agent 逻辑、工具调用和工作流代码更容易生成，真正更
 
 - `createAgentHarness(workspaceRoot)`、`request(...)`、`memorize(...)`、`recall(...)`、`listMemories(...)`、`updateMemory(...)`、`removeMemory(...)`、`resolveApproval(...)`、`subscribe(...)`、各类查询方法，以及 `stop(...)`
 - 以 YAML 描述的工作区装配：路由、模型、工具、存储、后端、MCP、恢复与维护等
-- 通过适配器对接当前的 LangChain v1 与 DeepAgents 执行
+- 通过适配器对接当前执行后端，并把对外运行时契约保持稳定
 - 本地 `resources/tools/` 中 `tool({...})` 工具模块与 `resources/skills/` 的发现
 - 持久化的会话、请求、审批、事件、队列状态与恢复元数据
 
@@ -242,7 +242,7 @@ AI 让 agent 逻辑、工具调用和工作流代码更容易生成，真正更
 
 默认原则是：
 
-- 若 LangChain v1 或 DeepAgents 已有能力，则在 YAML 中映射并在内部适配
+- 若执行后端已具备某项能力，则在 YAML 中映射并在内部适配
 - 除非问题确实属于运行时职责，否则不增加新的公共运行时 API
 
 建议从这些面向用户的文档开始（中文多页面在 `docs/development/zh/`）：
@@ -313,7 +313,7 @@ governance:
 
 - 你只需要一次短生命周期的 agent 调用，不需要审批、持久化或运维控制面
 - 你要的是工作流搭建器或低代码自动化画布
-- 你想替代 LangChain v1 或 DeepAgents 的执行语义，而不是围绕它们做运行时
+- 你想替代执行后端的语义，而不是围绕它们做运行时
 
 <a id="readme-zh-quickstart"></a>
 
@@ -393,7 +393,7 @@ try {
 - 多 agent 应用的工作区运行时
 - 精简的公共运行时契约
 - YAML 定义的主机路由与运行时策略
-- LangChain v1 与 DeepAgents 后端适配
+- 在统一运行时契约之后做后端适配
 - 自动发现本地工具与 SKILL 包
 - 原生 provider 工具、MCP 工具与工作区本地工具模块
 - 持久化会话、请求、审批、生命周期事件与排队请求
@@ -688,9 +688,9 @@ await stop(runtime);
 
 目前 `backend: langchain-v1` 这条路径的暂时限制是：
 
-- 在真实远端模型下，带 approval 的副作用工具调用稳定性弱于 DeepAgents 路径
+- 在真实远端模型下，带 approval 的副作用工具调用稳定性弱于轻量 direct-response 路径
 - 不建议把它作为长链路、多 agent、重 orchestration 流程的默认执行路径
-- 本包当前已把 DeepAgents 作为复杂运行时覆盖的默认主路径；只有在工作区明确需要 V1 行为时，才应显式选择 LangChain v1
+- 本包当前已把规划优先后端作为复杂运行时覆盖的默认主路径；只有在工作区明确需要轻量 direct-response 行为时，才应显式选择另一条后端路径
 
 实际建议：
 
@@ -816,7 +816,7 @@ spec:
 
 ### `config/catalogs/backends.yaml`
 
-可复用的 DeepAgents 后端预设，使文件系统与 `/memories/*` 拓扑保留在 YAML 中：
+可复用的后端预设，使文件系统与 `/memories/*` 拓扑保留在 YAML 中：
 
 ```yaml
 apiVersion: agent-harness/v1alpha1
@@ -946,11 +946,11 @@ spec:
 - 公共运行时契约保持通用且精简
 - 应用级编排与生命周期管理留在 harness 中
 - 外部协议边界应严格契合 `deepagents-acp`，而不是再做一套并行的 harness 私有协议
-- 应尽量在 YAML 中直接表达 LangChain v1 与 DeepAgents 的概念
+- 应尽量在 YAML 中直接表达执行后端的概念
 - 能用 YAML 表达的能力，优先 YAML 而非扩张公共 API
 - 恢复、审批、线程、运行与事件是运行时概念，不是后端逃生舱
 - 应用里的 task center 应基于现有 store 与 runtime id 建模，而不是把 task 扩成公共运行时契约
-- 新的 LangChain v1 或 DeepAgents 配置应先落在 YAML 映射与测试中，再考虑公共运行时 API
+- 新的后端配置应先落在 YAML 映射与测试中，再考虑公共运行时 API
 
 简言之：产品模型稳定，执行语义仍归上游。
 

package/dist/package-version.d.ts

@@ -1 +1 @@
-export declare const AGENT_HARNESS_VERSION = "0.0.236";
+export declare const AGENT_HARNESS_VERSION = "0.0.238";

package/dist/package-version.js

@@ -1 +1 @@
-export const AGENT_HARNESS_VERSION = "0.0.236";
+export const AGENT_HARNESS_VERSION = "0.0.238";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@botbotgo/agent-harness",
-  "version": "0.0.237",
+  "version": "0.0.239",
   "description": "Workspace runtime for multi-agent applications",
   "license": "MIT",
   "type": "module",