问题是怎么暴露的
我们在做 JVS Crew 的过程中，遇到过一个时刻：
团队辛苦维护了几个月的 Agent 流程图，因为上游模型升级，大量手写的 if-else 分支逻辑变得多余——但它不会自动消失，你必须手动清理。与此同时，新增一个边缘业务场景，意味着找到流程图里正确的插入点、新加节点、调整连线、重新回归测试。节点数量一旦超过几十个，理解这套流程图本身的成本就已经很高了。
这不是技术债，这是范式选错了。
两代范式，核心差异只有一句话
第一代：智能在流程里，模型是执行引擎。
工程师把任务拆成节点，用连线定义分支逻辑，模型只负责在每个节点"填空"。控制流是显式的、硬编码的。
第二代：智能在模型里，环境是执行舞台。
工程师构建沙箱、工具链、护栏和反馈循环，模型负责自主规划和动态决策。你不再告诉它"第一步做什么"，而是告诉它"你能用什么、你的边界在哪"，然后让它自己决定怎么做。
这个差异，带来的结果是：
| 维度 | 编排范式 | 环境范式 |
|---|---|---|
| 维护成本 | 随规则数量线性上升 | 只需更新 Prompt 和工具描述 |
| 能力天花板 | 受限于流程图覆盖范围 | 随模型能力提升自动抬升 |
| 资产价值 | 贬值资产 — 规则写死 | 增值资产 — 随模型进化增值 |
最关键的一点：编排范式产出的是贬值资产。 你根据当前模型能力设计的那套节点和分支，会随着模型升级而失效——但它不会自动修复自己。
为什么是现在切换
不是工程师主观想换代，是三个因素叠加让旧范式变得不经济：
1. 模型能力跨过了阈值。 2025-2026 年的模型，自主规划、多步骤工具调用、异常处理的能力已经成熟到足以托付控制权。"编排每一步"变成了一种限制，而不是保障。
2. 维护成本出现了拐点。 当维护一张流程图的成本，超过维护一套 Prompt 和工具描述的成本，旧账就算不过来了。
3. 投资逻辑根本变了。 投资流程是在投资一套特定于当前模型能力的规则；投资环境是在投资一套约束条件——模型越强，同一个约束环境能发挥的价值越大。每一次全球模型升级，你的平台都在被动获益。
行业独立验证了同一个方向
这不是一个团队的判断。2025-2026 年，多个头部团队独立走到了类似的结论：
- 某头部模型厂商把"大脑"（Agent）和"双手"（Environment）彻底拆开，Session 作为一等公民独立管理——不是请求-响应模型，是持久运行的执行实体
- 某云厂商提供最长 8 小时的持续执行，配合事件流和断线重连，中途断开进度不丢
- 某沙箱服务商把隔离执行做到 microVM 150ms 启动，为 Agent 脉冲式负载专门优化
我们 JVS Crew 团队是独立立项的，没有参照上述方案，但走出了类似的路。多个团队互不通气却得出同构结论，这是行业演进的信号，不是巧合。
我们怎么做的：Harness 四层架构
我们把"模型之外的部分"统称为 Harness。它不是功能堆砌，是一套控制架构：
┌─────────────────────────────────────┐
│ 接入层与消息网关 │
│ 钉钉 / 飞书 / 企微 / QQ 统一接入 │
├─────────────────────────────────────┤
│ 智能体编排与运行时 │
│ ReAct 推理循环 · Multi-Agent 协作 │
│ Context 分层管理 · 人机协同干预 │
├─────────────────────────────────────┤
│ 安全沙箱执行环境 │
│ 受控工具执行 · MCP Server 调用 │
│ 身份校验 · 技能预加载 │
├─────────────────────────────────────┤
│ 持久化数据层 │
│ 加密凭证托管 · 企业 Skill 资产 │
└─────────────────────────────────────┘
几个关键设计决策：
状态管理外部持久化，而不是压缩上下文。 Session 是独立的持久化事件日志，Harness 灵活查询和恢复状态。任务超出上下文窗口时，不做不可逆的信息丢弃。
工具集成全面转向 MCP 标准协议。 写一次工具连接器，跨框架和模型复用。不锁定在任何特定框架里。
控制流从黑盒变成可观测的事件流。 SSE 实时透出模型的思考、工具调用、执行结果。执行（生成）和监控（评估）是独立的两个环节，工程师可以介入。
渐进式启用。 只开核心三层就是托管型 Agent 运行时，全部开启才是完整企业级平台。企业可以按需解锁多租户、权限、审计、计费。
两个使用模式，共用同一套底座
| 模式 | 体验 | 适用场景 |
|---|---|---|
| 声明式配置 + 全托管 | 控制台配置 Agent Profile、System Prompt、安全围栏、技能组合、Channel，一键交付 | 企业内部快速构建和上线 Agent |
| 原子化 API | REST API + 多语言 SDK，Session 管理、双向事件流、人在回路 | ISV 集成进自有产品，深度定制 |
C 端个人版（JVS Claw）和 B 端企业版（JVS Crew）共用同一套 Harness 架构——Agent 执行层本质没有区别，区别只在外围的多租户、权限、审计、计费。
一个不那么确定的预测
有人说 Harness 最终会消亡——随着模型足够强，工具选择、错误恢复、上下文管理都会由模型自主完成，Harness 会收缩为一个极简的"护栏"。
我们的判断是：形态会变，但核心价值不会消失。把模型的智能约束在安全、可控、可观测的环境中，这件事本身不会过时。 一个能执行任意代码的 AI 系统，既强大又危险。Harness 是唯一一种既能放开手让 Agent 干活、又能管控它的方式。
给正在构建 Agent 产品的团队
如果你现在还在维护一张复杂的流程图，可以问自己几个问题：
- 这套流程，在模型升级后能自动受益，还是必须手动修改？
- 你的状态管理是内存里的对话历史，还是外部持久化的事件日志？
- 你的工具集成是框架专属的包装器，还是基于 MCP 这样的标准协议？
范式跃迁不是选择题，是时间问题。越早把投资方向从"流程"转向"环境"，后面的维护账越好算。
