前面研究 Codex、Agent、Tool、MCP 和记忆时，我逐渐有了一个疑问：每家公司的业务都不一样，真的可以直接使用同一套 Agent 吗？
我的理解是，可以共用同一个通用 Harness 内核，但不能共用完全相同的业务规则。
模型解决的是通用理解和推理问题，Harness 解决的是怎么让模型持续完成任务；企业业务 Harness 还要进一步解决数据、权限、流程、验收和责任边界。
1. Codex 这类通用 Harness 提供什么
Codex 不只是一个模型调用界面。它周围还有一套通用 Agent 运行能力，例如：
- 管理会话和上下文。
- 调用模型并处理多轮执行。
- 提供文件、Shell、浏览器等工具。
- 接入 Skill、MCP 和其他 Agent。
- 执行沙箱、权限和审批规则。
- 展示过程、保存状态并处理失败。
- 在多轮任务中继续已有工作。
OpenAI 官方把这层定义为开放的 Agent Harness。官方说明中提到，Codex App、CLI 和 IDE Extension 共用底层 Harness；它负责收集上下文、使用工具、遵守配置边界、请求批准并让工作跨轮继续。Codex as a platform：开放 Agent Harness
这些能力很通用，研发、运维、安全和内部应用都能使用。
但 Codex 默认不知道某个企业的订单状态机、支付审批规则、发布流程和内部验收标准。通用 Harness 提供的是发动机，不是已经配置好的业务车辆。
2. 为什么不同业务线需要不同 Harness
同一个模型面对不同业务时，需要遵守的规则并不相同。
| 业务场景 | 需要的上下文 | 主要工具 | 关键控制 |
|---|---|---|---|
| 研发 | 代码、工单、测试结果 | Git、构建、日志、发布 | 写入授权、测试、代码审查 |
| 客服 | 用户问题、产品文档、历史工单 | 查询订单、知识库、回复系统 | 隐私、话术、人工接管 |
| 订单 | 商品、库存、订单状态 | 订单服务、库存服务 | 状态机、幂等、补偿 |
| 支付 | 支付记录、风控信息 | 支付服务、风控服务 | 高权限、审计、强审批 |
它们可能使用同一个模型，也可能共用相同的 Tool Calling 和 Memory 组件，但下面这些内容必须按业务区分：
- 什么数据允许进入模型上下文。
- 哪些工具对当前 Agent 可见。
- 什么操作可以自动执行。
- 什么操作必须由用户审批。
- 失败后应该重试、补偿还是停止。
- 什么结果才算任务完成。
- 日志、记忆和审计记录保存多久。
因此，不同业务 Harness 的差异主要不在模型，而在模型外面的业务控制层。
3. 不需要每条业务线重新造一个框架
如果每个部门都单独开发一整套 Agent 框架，会重复建设模型调用、会话、权限、重试、追踪和评测能力。
更合理的方式是：企业维护一套共享 Harness 内核，每条业务线只提供自己的业务包。
共享内核主要负责：
模型调用
会话与上下文
工具调用循环
通用重试与超时
权限和审批基础能力
记忆框架
模型路由
Token 与成本统计
Trace 和 Evaluation
业务包主要负责：
Agent 角色
业务 Skill
Tool / MCP
业务知识库
流程状态机
写操作权限
失败补偿规则
业务验收标准
这样既保留统一治理能力，也允许每条业务线拥有自己的专业规则。
4. 私有化 Harness 不等于私有化模型
很多人提到私有化 AI，会直接想到在公司内部部署一个大模型。
实际上，Harness 和模型可以分别部署。
方案一：私有 Harness + 云端模型
企业内部保存业务规则、记忆和工具
模型推理由云端厂商提供
它的建设成本较低，能够快速使用能力较强的模型。但发送给模型的内容仍然要经过数据过滤，并遵守厂商的数据策略。
方案二：私有 Harness + 多模型网关
Harness 不直接绑定某个模型厂商
所有模型请求先经过企业模型网关
模型网关负责路由、限流、密钥、成本、降级和审计。普通任务可以使用便宜模型，复杂任务使用更强模型，敏感任务可以转到本地模型。
方案三：Harness 和模型全部私有化
Harness、记忆、工具和模型都部署在企业内部
数据控制最强，但模型部署、GPU、推理引擎、并发、升级和运维成本也最高。
对大多数企业来说，更现实的通常是混合模式。
5. 企业真正需要私有化的是什么
对企业来说，最需要掌握在自己手里的往往不是模型权重，而是下面这些内容。
业务上下文
包括工单、订单、日志、代码、产品文档和用户状态。Harness 决定哪些内容可以进入当前模型上下文。
记忆和知识库
用户偏好、项目结论、业务知识和任务检查点应由企业控制。模型只能读取当前任务需要的少量内容。
Tool 和 MCP
模型可以建议调用工具，但真正的工具执行由企业系统完成。工具需要权限、参数校验、幂等、超时和审计。
权限与审批
查询、修改、发布、付款和发送通知属于不同权限层。不能因为模型判断“应该执行”，就自动获得业务权限。
状态、重试和回滚
订单失败可能需要补偿，研发失败可能需要重新测试，支付超时必须先查询状态。失败处理无法只靠通用重试规则解决。
Evaluation 与审计
企业需要知道 Agent 调用了几次模型、使用了什么工具、消耗多少 Token、为什么做出某个决定，以及最终结果是否正确。
这些才是企业业务 Harness 的核心资产。
6. 一个业务请求怎么经过私有 Harness
这里的模型只是其中一个执行环节。真正让任务形成闭环的是 Harness 对上下文、权限、工具、状态和停止条件的控制。
7. 失败处理为什么必须业务化
通用 Harness 可以处理网络超时、429、5xx 和格式校验错误，但业务失败需要更具体的规则。
例如：
| 失败情况 | 处理方式 |
|---|---|
| 查询工具超时 | 可以重试或切换只读工具 |
| 写操作响应超时 | 先查询执行状态，不能直接重复写入 |
| 非关键节点失败 | 使用默认值或标记部分成功 |
| 关键节点失败 | 停止所有依赖节点 |
| 上游结果未变化 | 复用成功检查点，只重跑失败节点 |
| Token 达到预算 | 停止自动重试，返回已有结果 |
这也是业务 Harness 与普通聊天客户端的重要区别：聊天失败可以重新回答，业务执行失败则可能影响真实状态。
8. 推荐的渐进式落地方式
企业不需要一开始就搭建一个庞大的 Agent 平台。
第一阶段：使用通用 Harness
直接使用 Codex、Spring AI 或其他现有框架，先完成一个边界清晰的只读任务。
目标是验证：模型是否能理解任务，工具结果是否足够，业务验收标准是否明确。
第二阶段：增加业务配置
加入业务 Agent、Skill、MCP、知识库、权限和结构化输出。此时仍然复用现有 Harness 的会话和工具循环。
第三阶段：形成私有控制层
统一管理任务状态、记忆、重试、审批、Token 成本、Trace 和 Evaluation。业务系统不再直接调用模型厂商。
第四阶段：建设模型网关
当模型种类、调用量、成本和合规要求明显增加后，再统一处理多模型路由、限流、缓存和降级。
第五阶段：抽取共享内核
只有多个业务场景已经稳定运行后，才把重复部分抽象成企业 Harness 平台。不要先造一个万能框架，再寻找业务场景。
9. 容易走偏的几个方向
把所有业务规则写进一个 Prompt
Prompt 会越来越长，规则互相冲突，也无法可靠处理权限和状态。
每条业务线重新造一套 Agent 框架
模型接入、会话、重试、记忆和追踪被重复建设，后续很难统一治理。
把私有化等同于部署本地模型
模型放在本地，不代表工具、权限、记忆和业务流程已经安全可靠。
一开始就追求多 Agent
如果单 Agent、工具和验收标准都没有稳定，多 Agent 只会增加调用次数和问题定位成本。
只看最终回答，不做 Evaluation
没有任务成功率、工具成功率、Token、耗时和失败分类，就无法判断 Harness 是否真的优于普通模型调用。
总结
企业 AI 可以分成三层：
模型：提供通用智能
通用 Harness：提供 Agent 运行循环
业务 Harness：提供企业流程、数据、权限和验收
Codex 这类通用 Harness 可以作为起点。OpenAI 官方也建议应用继续拥有产品上下文、业务规则和工具，而 Codex app-server 提供 Agent Loop 和隔离执行；开发者可以通过 SDK、app-server 或非交互方式把这套能力接入自己的产品。Codex Harness 的集成层
私有化 Harness 的价值，不是再造一个聊天客户端，而是让企业能够控制：
给模型什么
允许模型做什么
失败以后怎么办
什么时候必须由人决定
怎样证明任务真的完成
因此，我更看好下面这种形态：
共享的通用 Harness 内核，加上按业务隔离的 Agent、记忆、Tool、权限、流程和 Evaluation，再通过模型网关连接云端或本地模型。
模型可以更换，企业真正需要长期积累的是自己的业务 Harness。
