LocalCortex工作空间：智能体运行的宪法级契约

1. 工作空间不是“文件夹”，而是智能体的运行宪法

“选错一次工作空间，智能体就白忙一场”——这句话不是夸张，是我在连续三天重跑同一个RPA流程、反复调试同一段代码生成逻辑、最终发现所有输出都卡在本地缓存目录里时，盯着控制台里那行不起眼的workspace: /tmp/harness_temp报错信息，一拳砸在桌面上的真实反应。

很多人把 LocalCortex（以及它背后代表的 harness 类框架）里的“工作空间”（Workspace）当成 Windows 里的“我的文档”或者 VS Code 里的“打开文件夹”。错了。它根本不是存储路径的别名，而是一套运行时契约的物理载体：它定义了智能体能读什么、写哪里、调用哪些插件、加载哪套技能（Skill）、信任哪个模型端点、甚至决定了日志该打到哪个通道、错误该回滚到哪一层。你选错工作空间，等于给一个外科医生发了一套牙科器械包，还告诉他“手术室就在隔壁B302”——他技术再好，也切不到该切的地方。

我见过最典型的误操作，就是直接双击.harness文件启动 LocalCortex，结果它自动挂载了默认的~/.localcortex/workspace/default。这个 default 空间里只预装了基础 CLI 插件和一个哑巴模型代理，没有 RPA 驱动、没有文件系统权限策略、没有 Git Hook 集成 Skill。你拖进去一个 Excel 处理流程，它连 sheet 名都解析不出来；你配置好 DeepSeek-Coder 的 API 地址，它却坚持走内置的 mock 模型路由。不是模型不行，是工作空间没授权它调用。

更隐蔽的问题出在多项目协作场景。团队里 A 同学用workspace-prod跑生产级代码审查，B 同学用workspace-dev做本地提示词迭代，两人共享同一台机器。某天 B 同学为了测试一个新插件，临时把workspace-dev的plugins/目录软链到了workspace-prod的plugins/下——结果第二天 A 同学提交的 PR 自动检查全挂了，因为 prod 空间里混进了 dev 环境才该启用的 debug 日志插件，触发了 CI 流水线的敏感日志拦截规则。问题根源不在插件本身，而在 workspace 的边界被人为撕开了。

LocalCortex 的设计哲学很明确：工作空间即沙盒，沙盒即上下文，上下文即决策依据。它不靠进程隔离、不靠用户权限、不靠环境变量污染来区分任务域，而是用一套声明式 JSON Schema + 文件系统硬隔离 + 运行时校验三重机制，强制你在启动前就回答三个问题：

• 这个任务要访问哪些外部资源？（resources字段声明）
• 它允许加载哪些插件？（allowed_plugins白名单）
• 它的技能执行链路是否经过审计？（skill_chain的哈希签名）

这解释了为什么harness failed to load plugins web boot: 1 entry did not activate huayu-yuan这类报错总在切换 workspace 后爆发——不是插件坏了，是你当前 workspace 的allowed_plugins列表里压根没写huayu-yuan这个 ID，LocalCortex 在加载阶段就把它踢出了执行队列。它宁可报错，也不让你在错误的宪法下运行。

所以，“根治”的第一步，从来不是找插件、调参数、换模型，而是重建工作空间的主权意识。你不是在选一个存放文件的地方，你是在签署一份运行合约。合约签错了，后面所有努力都是无效劳动。

2. LocalCortex 工作空间的三层物理结构与权限映射

LocalCortex 的工作空间不是扁平目录，它是一个有严格层级、每层承担不同职责的立体结构。我拆解过 7 个主流 workspace 模板（包括 deepseek-harness-official、claudecode-harness、轩辕编程定制版），它们表面目录名各异，但底层骨架惊人一致。理解这三层结构，是避免“白忙一场”的技术基础。

2.1 第一层：根契约层（Root Contract Layer）

路径：<workspace-root>/contract.json
这是整个 workspace 的宪法性文件，LocalCortex 启动时第一个读取、最后一个校验的对象。它不包含任何业务逻辑，只定义四件事：

• 身份标识："id": "ws-prod-code-review-2024q3"—— 不是随便起的名字，LocalCortex 会用它生成 workspace 的唯一 SHA256 指纹，用于插件签名验证。
• 能力边界："allowed_resources": ["file:///", "http://localhost:8000", "[e-mail]:org/repo.git"]—— 注意，这里写的是 URI Scheme，不是路径。file:///表示允许读写任意本地文件，file://./才表示仅限当前 workspace 目录下。很多权限问题就栽在这里。
• 插件白名单："allowed_plugins": ["rpa-driver-v2", "git-hook-skill", "deepseek-coder-api"]—— 必须是插件 manifest.json 中声明的"id"，大小写敏感。huayu-yuan和HuayuYuan是两个插件。
• 技能链签名："skill_chain_hash": "sha256:abc123..."—— 这个哈希值由 LocalCortex 根据skills/目录下所有.skill.json文件内容计算得出。只要改一个 skill 的 description，hash 就变，启动失败。

提示：contract.json一旦生成，禁止手动修改。LocalCortex 会在启动时比对当前文件 hash 与skill_chain_hash是否一致。不一致？直接拒绝启动，并提示Contract integrity violation: skill chain modified。这不是 bug，是设计。

2.2 第二层：能力供给层（Capability Supply Layer）

路径：<workspace-root>/plugins/和<workspace-root>/skills/
这才是你日常打交道的目录，但它的行为完全受第一层约束。

• plugins/目录下放的是插件包（zip 或文件夹），每个包必须含manifest.json。LocalCortex 只加载contract.json中allowed_plugins列表里出现的 ID 对应的插件。其他插件会被静默忽略——连日志都不打。这就是为什么你把huayu-yuan.zip放进 plugins 目录，却看到1 entry did not activate的原因：contract 里没写它。

• skills/目录下放的是技能定义文件（.skill.json），每个文件描述一个原子能力，比如“从 Excel 提取表头”、“生成 Git Commit Message”。LocalCortex 会按contract.json中skill_chain_hash验证这些文件完整性，然后构建技能执行图。技能文件里可以声明required_plugins，如果该插件不在allowed_plugins白名单里，这个 skill 就永远处于unavailable状态。

我实测过一个典型陷阱：某 deepseek harness 插件推荐列表里提到“支持 Excel 处理”，但没说清楚它依赖rpa-driver-v2插件。你装了插件，写了 skill，启动时报Skill 'excel-parser' requires plugin 'rpa-driver-v2' which is not allowed in this workspace。解决方案不是卸载插件，而是去contract.json的allowed_plugins里加上"rpa-driver-v2"，再重新生成skill_chain_hash。

2.3 第三层：数据契约层（Data Covenant Layer）

路径：<workspace-root>/data/和<workspace-root>/cache/
这是智能体实际干活的地方，但它的读写权限由第一层allowed_resources严格管控。

• data/是你的输入输出区。LocalCortex 默认只允许智能体读写data/目录下的文件。如果你的 skill 写了fs.readFile('/home/user/report.xlsx')，而 contract 里allowed_resources没包含file:///home/user/，就会抛出Permission denied: file:///home/user/report.xlsx。Windows 上常见报错setnamedsecurityinfow failed (win32)，本质是 LocalCortex 的安全模块在尝试为data/目录设置 NTFS ACL 时失败，因为当前用户没有SeSecurityPrivilege权限——这不是插件问题，是 workspace 初始化阶段的系统权限缺失。

• cache/是 LocalCortex 的内部缓存区，用于模型响应、插件元数据等。它不对外开放读写，但它的位置会影响性能。默认在cache/下，但你可以通过contract.json的"cache_location"字段指定到 SSD 分区，比如"cache_location": "file:///mnt/ssd/localcortex-cache"。注意，这个路径必须出现在allowed_resources列表里，否则启动失败。

这三层结构形成闭环：contract 定义“能做什么”，plugins/skills 提供“怎么做”，data/cache 承载“做成了什么”。任何一层错位，都会导致智能体在启动、加载、执行任一环节卡死。所谓“白忙一场”，往往就发生在你花了两小时调通 skill 逻辑，却忘了更新 contract 的skill_chain_hash，结果重启后一切归零。

3. Workspace 初始化的四个致命陷阱与绕过方案

LocalCortex 官方文档里 workspace 初始化只有三行命令，但我在真实项目中踩过的坑，90% 都集中在初始化阶段。不是命令写错了，而是命令背后的隐含契约被忽略了。下面四个陷阱，每一个都曾让我重装系统、重配环境、重写技能链。

3.1 陷阱一：harness init自动生成的 contract 是“最小可用”，不是“生产就绪”

当你运行harness init --name my-workspace，LocalCortex 会创建一个contract.json，里面allowed_resources只写了["file://./"]，allowed_plugins是空数组[]。它能跑起来，但什么也干不了。

新手常犯的错误，是以为“先跑起来再说”，结果在skills/里写了个调用 GitHub API 的 skill，启动就报Resource 'https://api.github.com' not allowed。这时候去查文档，发现要手动编辑contract.json加上"https://api.github.com"——但加完保存，LocalCortex 却报Contract integrity violation。

原因在于：harness init生成的 contract 里skill_chain_hash是基于空skills/目录算的。你加了 skill 文件，hash 就变了，但 contract 没更新。正确流程是：

1. 先清空skills/目录；
2. 编辑contract.json，加入你需要的allowed_resources和allowed_plugins；
3. 运行harness workspace sign（这是关键！），它会扫描skills/目录，重新计算 hash，覆盖contract.json中的skill_chain_hash字段；
4. 最后放 skill 文件进去。

注意：harness workspace sign命令必须在 workspace 根目录下运行，且要求skills/目录存在。如果skills/是空的，它会生成一个空 hash，后续加 skill 仍需重签。

3.2 陷阱二：离线环境下的插件签名验证失败

deepseek harness可以在离线局域网使用吗？——可以，但必须提前处理签名。LocalCortex 默认从官方插件仓库下载插件时，会验证其数字签名。离线环境下，它找不到公钥服务器，启动就卡在Verifying plugin signature...。

绕过方案不是关掉签名验证（那会破坏安全模型），而是预加载可信公钥。步骤如下：

1. 在联网机器上，运行harness plugin list --verbose，找到你要用的插件（如deepseek-coder-api），记下它的publisher_id（通常是deepseek-org）；
2. 运行harness key export --publisher deepseek-org > deepseek.pub，导出公钥；
3. 把deepseek.pub文件拷贝到离线机器的<workspace-root>/keys/目录下（需手动创建）；
4. 在contract.json中添加"trusted_publishers": ["deepseek-org"]。

这样 LocalCortex 启动时，会优先从本地keys/目录找公钥，跳过网络请求。我试过在无网的军工内网部署，这套流程稳定运行了 11 个月。

3.3 陷阱三：Windows 权限导致data/目录初始化失败

deepseek harness 桌面版 写综述场景下，用户双击 exe 启动，LocalCortex 尝试在data/目录创建子目录用于缓存 Excel 解析结果，却报setnamedsecurityinfow failed (win32)。这不是插件 bug，是 Windows UAC 限制。

根本原因是：LocalCortex 默认以当前用户权限启动，但data/目录若位于Program Files或需要管理员权限的路径下，普通用户无法设置 NTFS ACL。解决方案有两个：

• 推荐：把 workspace 创建在用户目录下，比如C:\Users\YourName\Documents\harness-workspaces\my-project。LocalCortex 会自动获得完整权限。
• 强制方案：以管理员身份运行 LocalCortex，但必须在首次启动时完成data/目录初始化，之后可降权运行。注意，管理员启动后生成的contract.json里cache_location可能指向C:\ProgramData\，这个路径普通用户依然无权写入，需手动改回用户目录。

3.4 陷阱四：harness install插件时的路径污染

deepseek harness安装教程常教人运行harness install https://example.com/plugin.zip。问题在于，这个命令会把插件解压到全局插件目录（如~/.localcortex/plugins/），而不是当前 workspace 的plugins/目录。结果就是：插件装上了，但contract.json里没声明，LocalCortex 视而不见。

正确做法永远是：

1. 下载插件 zip 到本地；
2. 手动解压到<workspace-root>/plugins/<plugin-id>/目录下；
3. 确保解压后目录里有manifest.json；
4. 更新contract.json的allowed_plugins数组，加入该插件 ID；
5. 运行harness workspace sign。

harness install命令只适用于快速原型验证，生产环境必须走手动路径。我见过团队因这个疏忽，导致上线后发现 3 个关键插件始终未激活，回滚耗时 4 小时。

这四个陷阱共同指向一个事实：LocalCortex 的 workspace 初始化不是“安装软件”，而是“签署一份带技术条款的法律合同”。你跳过任何一个验证环节，合同就无效，智能体就无法履职。

4. 工作空间诊断工具链：从报错日志到根因定位的完整链路

当 LocalCortex 报错harness failed to load plugins web boot: 1 entry did not activate huayu-yuan或deepseek harness无法安装时，90% 的人会立刻重装、换版本、搜论坛。但真正高效的解决者，会启动一套标准化的诊断工具链。这套链路我用了两年，覆盖了 37 类 workspace 相关故障，平均定位时间从 2 小时缩短到 11 分钟。

4.1 第一层诊断：启动日志的三段式解读法

LocalCortex 的启动日志不是流水账，而是按阶段分块的。关键不是看最后一行报错，而是看报错前 3 行、报错后 2 行、以及报错所在阶段的头部摘要。

以1 entry did not activate huayu-yuan为例，完整日志片段如下：

[BOOT] Loading plugins from /path/to/workspace/plugins/ [PLUGIN] Found plugin 'huayu-yuan' at /path/to/workspace/plugins/huayu-yuan/ [CONTRACT] Validating plugin 'huayu-yuan' against allowed_plugins list... [CONTRACT] Plugin 'huayu-yuan' not found in allowed_plugins whitelist. [BOOT] Failed to activate 1 plugin: huayu-yuan

解读链路：

• [BOOT] Loading plugins...→ 确认插件物理存在，路径正确；
• [PLUGIN] Found plugin...→ 确认插件结构合规（有 manifest.json）；
• [CONTRACT] Validating...→ 进入核心校验环节；
• [CONTRACT] Plugin 'huayu-yuan' not found...→根因在此：contract 白名单缺失；
• [BOOT] Failed to activate...→ 结果呈现。

所以，看到1 entry did not activate，第一反应不是查插件，而是cat contract.json | jq '.allowed_plugins'，确认huayu-yuan是否在列表里。不在？补上，再harness workspace sign。

4.2 第二层诊断：harness workspace verify的深度扫描

LocalCortex 自带的verify命令远比想象中强大。它不只是检查 JSON 格式，而是模拟整个启动流程的轻量版执行：

harness workspace verify --verbose

输出会分五块：

• Contract Integrity：验证skill_chain_hash是否匹配skills/内容；
• Plugin Validation：逐个检查plugins/下每个插件的manifest.json是否符合 schema，ID 是否与目录名一致；
• Resource Accessibility：尝试ping或statallowed_resources里每个 URI，报告可访问性（如file:///tmp/是否可写）；
• Skill Chain Consistency：解析所有.skill.json，检查required_plugins是否都在白名单里，depends_on的 skill 是否存在；
• Cache Health：扫描cache/目录，报告是否有损坏的 blob 文件。

我遇到过一次deepseek harness 代码回退失败，日志只显示Git operation failed。运行harness workspace verify后，第三块Resource Accessibility显示：[e-mail]:org/repo.git -> Permission denied (publickey)。原来 workspace 的allowed_resources里写了 git URL，但没配 SSH key。verify命令直接定位到权限配置缺失，而非 Git 插件本身问题。

4.3 第三层诊断：harness debug trace的执行流快照

当 skill 执行卡住或返回意外结果时，--debug参数只能看到最终报错。真正的利器是harness debug trace，它会生成一个 JSON 格式的执行流快照，记录每个 skill 的输入、输出、耗时、调用的插件、甚至模型原始响应。

用法：

harness run skill:excel-parser --input data/input.xlsx --debug-trace trace.json

生成的trace.json结构清晰：

{ "skill_id": "excel-parser", "start_time": "2024-06-15T10:22:33Z", "steps": [ { "step": "load_file", "plugin": "file-reader-v1", "input": {"path": "data/input.xlsx"}, "output": {"content_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", "size_bytes": 12456}, "duration_ms": 42 }, { "step": "parse_sheet", "plugin": "excel-parser-v2", "input": {"sheet_name": "Sheet1"}, "output": {"error": "Permission denied: file:///tmp/excel-temp-dir/"}, "duration_ms": 187 } ] }

看到Permission denied，立刻意识到excel-parser-v2插件试图写临时文件到/tmp/，但contract.json的allowed_resources只允许file://./（即 workspace 根目录）。解决方案：要么改插件配置指向data/temp/，要么在 contract 里加上file:///tmp/——但后者不安全，推荐前者。

4.4 第四层诊断：自建 workspace 健康检查脚本

我把上述诊断逻辑封装成一个 Bash 脚本workspace-check.sh，放在每个 workspace 根目录下，一键运行：

#!/bin/bash echo "=== Workspace Health Check ===" echo "1. Contract integrity..." harness workspace verify --quiet || echo "❌ Contract invalid" echo "2. Plugin whitelist sync..." if ! jq -e '.allowed_plugins | index("huayu-yuan")' contract.json >/dev/null; then echo "❌ huayu-yuan missing from whitelist" fi echo "3. Data directory permissions..." if [ ! -w data/ ]; then echo "❌ data/ not writable" fi echo "4. Cache directory size..." CACHE_SIZE=$(du -sh cache/ | cut -f1) if [[ $CACHE_SIZE == *"G"* ]] && [ $(echo $CACHE_SIZE | sed 's/G//') -gt 5 ]; then echo "⚠️ cache/ > 5GB, consider cleanup" fi

这个脚本不解决所有问题，但它把 80% 的 workspace 配置类故障，压缩成 4 行可读输出。团队新人入职，第一件事就是跑这个脚本，而不是翻文档。

诊断的本质，不是找 bug，而是验证契约的履行状态。LocalCortex 的设计哲学决定了：所有故障，最终都可归结为 contract、plugins、skills、data 四者之间的契约断裂。工具链的作用，就是帮你快速定位断裂点在哪一层。

5. 生产级 workspace 模板设计：从单机开发到跨团队协同的演进

“根治”工作空间问题，终极方案不是修 bug，而是建立一套可持续演进的 workspace 模板体系。我服务过的 12 个团队，最终都走上了这条路。它不是一蹴而就，而是分三个阶段演进：单机验证 → 团队共享 → 生产发布。

5.1 阶段一：单机开发模板（Dev Template）

目标：让一个开发者能在 5 分钟内启动一个功能完备的 workspace，用于原型验证。

核心设计原则：最小必要权限 + 最大可调试性。

• contract.json示例：

{ "id": "dev-template-2024", "allowed_resources": ["file://./", "http://localhost:8000", "https://api.deepseek.com"], "allowed_plugins": ["file-reader-v1", "deepseek-coder-api", "console-logger"], "trusted_publishers": ["deepseek-org"] }

• plugins/只放 3 个插件，全部来自官方源，签名已预加载；
• skills/包含 2 个 demo skill：hello-world.skill.json和test-api-call.skill.json，输入输出明确；
• data/预置sample.xlsx和test-input.txt，供 skill 直接调用；
• 根目录下放README.md，写明harness run skill:hello-world即可验证。

这个模板的价值，在于消灭“环境差异”。新人 clone 仓库，cd workspace-dev && harness start，就能看到 “Hello, World!” 输出。没有“我这边好使，你那边不行”的扯皮。

5.2 阶段二：团队共享模板（Team Template）

目标：让多个开发者在不同机器上，用同一套 workspace 配置协作，保证行为一致。

核心挑战：环境异构性（Mac/Win/Linux）、权限差异（个人电脑/公司笔记本）、网络策略（能否访问公网 API）。

解决方案：参数化 contract + 环境感知脚本。

• contract.json不再是静态文件，而是 Jinja2 模板contract.j2：

{ "id": "{{ workspace_id }}", "allowed_resources": [ "file://./", {% if env == 'prod' %}"https://api.company.com"{% else %}"http://localhost:8000"{% endif %}, "https://api.deepseek.com" ], "allowed_plugins": ["file-reader-v1", "deepseek-coder-api"], "trusted_publishers": ["deepseek-org"] }

• 提供setup-workspace.sh脚本，根据当前环境自动渲染：

#!/bin/bash ENV=${1:-dev} WORKSPACE_ID="team-${ENV}-$(date +%Y%m%d)" jinja2 contract.j2 -D env=$ENV -D workspace_id=$WORKSPACE_ID > contract.json harness workspace sign

• plugins/目录改为 Git 子模块，指向内部 Nexus 仓库的插件包，确保所有人用同一版本；
• skills/目录启用 Git LFS，管理大体积 Excel 模板文件；
• data/目录.gitignore排除所有文件，只保留schema.json描述数据结构。

我们团队用这套模板后，跨平台协作的故障率下降 73%。Mac 开发者写的 skill，在 Windows CI 机器上 100% 通过，因为 contract 的allowed_resources是根据env动态生成的，不是硬编码。

5.3 阶段三：生产发布模板（Prod Template）

目标：将 workspace 作为可部署、可审计、可回滚的制品，交付给运维或客户。

核心要求：不可变性 + 审计追踪 + 灾难恢复。

实现方式：workspace 归档 + 签名 + 清单文件。

• 构建时，运行harness workspace archive --output ws-prod-20240615.tar.gz，它会：

  • 打包contract.json、plugins/、skills/、keys/（不含data/和cache/）；
  • 生成MANIFEST.json，记录所有文件的 SHA256；
  • 用团队私钥对整个 tar.gz 签名，生成ws-prod-20240615.tar.gz.sig。

• 发布时，运维只需：

  # 验证签名 gpg --verify ws-prod-20240615.tar.gz.sig # 解压 tar -xzf ws-prod-20240615.tar.gz # 启动（自动校验 contract integrity） harness start

• 回滚时，直接换回上一个版本的 tar.gz，无需重新配置。deepseek harness附带skill怎么部署到内网服务器的难题，至此变成标准的制品部署流程。

这个模板让我们的客户验收周期从 2 周缩短到 2 天。他们不再问“怎么装”，而是直接运行harness start，看到绿色READY就签字。

从单机到团队再到生产，workspace 模板的演进，本质是从“个人工作区”到“组织级契约”的升级。它不再是一个人的配置，而是一份可执行、可验证、可传承的技术协议。

6. 关于 Harness 与 Agent 的本质区别：为什么工作空间是 Harness 的灵魂

网络热词里频繁出现agent harness、harness和agent区别、agent harness:驾驭al agent，这说明很多人还没看清 Harness 的本质。它不是另一个 Agent 框架，而是 Agent 的操作系统。理解这一点，才能真正明白工作空间为何如此关键。

6.1 Agent 是“应用”，Harness 是“操作系统”

把 Agent 想象成 Word 文档——它有内容、有格式、有作者，但它不能自己运行，必须依赖操作系统（Windows/macOS）提供文件读写、网络访问、UI 渲染等能力。

Harness 就是那个操作系统。它不决定 Agent 做什么（那是 skill 和 prompt 的事），而是决定 Agent能做什么、在哪里做、用什么工具做、对谁负责。

• 能做什么→ 由contract.json的allowed_resources和allowed_plugins定义；
• 在哪里做→ 由 workspace 的物理路径和data/目录绑定；
• 用什么工具做→ 由plugins/目录提供的能力集决定；
• 对谁负责→ 由contract.json的id和签名，将执行结果锚定到具体 workspace 实例。

所以deepseek harness不是“DeepSeek 的 Agent”，而是“运行 DeepSeek Agent 的 Harness 实例”。你换一个 workspace，等于换了一个操作系统实例——Word 文档还在，但新系统里没装 Office，它就打不开。

6.2 工作空间是 Harness 的“进程隔离”机制

传统 Agent 框架（如 LangChain、LlamaIndex）靠 Python 进程隔离、线程隔离来区分任务。Harness 用工作空间实现文件系统级隔离，这是更彻底、更安全的隔离。

• 进程隔离：两个 Agent 实例可能共享内存、环境变量、甚至模型缓存，一个崩了可能影响另一个；
• 工作空间隔离：每个 workspace 有独立的data/、cache/、plugins/、contract.json，物理路径不重叠，权限策略独立，一个 workspace 的skill_chain_hash错误，绝不会影响另一个。

我做过压力测试：在同一台机器上并行启动 12 个不同 workspace（分别对应 12 个客户），每个 workspace 运行独立的 RPA 流程。当其中一个 workspace 因data/磁盘满而崩溃时，其余 11 个继续平稳运行，日志里没有任何干扰。这种稳定性，源于工作空间的硬隔离。

6.3 Harness 的扩展性来自 workspace 的组合能力

harness anything、harness engineering这些热词，指向 Harness 的终极能力：组合。不是写一个大而全的 Agent，而是用多个小 workspace 组合出复杂系统。

例如，一个“智能代码审查”流程，可以拆解为：

• ws-git-hook：监听 PR，提取 diff，存到data/diff.patch；
• ws-code-analyzer：读取data/diff.patch，调用 DeepSeek-Coder API，生成 review comment，存到data/review.json；
• ws-comment-publisher：读取data/review.json，调用 GitHub API 发布评论。

三个 workspace 独立部署、独立更新、独立审计。ws-git-hook的 contract 只允许访问 Git webhook，ws-code-analyzer的 contract 只允许调用 DeepSeek API，ws-comment-publisher的 contract 只允许访问 GitHub。任何一个环节出问题，都不会泄露其他环节的密钥或数据。

这种“微 workspace”架构，正是harness + rpa落地实现能成功的关键——它把复杂系统，分解为一组契约清晰、边界明确、可独立演进的小单元。

所以，当你看到选错一次工作空间，智能体就白忙一场，请记住：这不是 LocalCortex 的缺陷，而是它的设计哲学。它强迫你思考——在这个任务里，智能体到底需要什么权限、什么工具、什么数据？想清楚了，再签那份 contract。签错了，当然白忙；签对了，它就是你最可靠的数字同事。

我在实际项目中发现，团队花在 workspace 设计上的时间，前期看似慢，但后期节省的调试、协作、上线时间，是前期投入的 7 倍以上。最值得的投资，永远是厘清责任边界的那一刻。