方案总览¶
我们开发的是什么¶
我们要开发的是一个 企业级 Agent Harness / Agent Operating Platform。
它不是单纯的 hooks，也不是一组 skills，更不是复制某个 agent 框架的源码。它的定位是：
底层调用成熟 agent runtime，上层沉淀企业上下文、工具权限、流程编排、审计、评测和人工确认机制。
为什么不是 skills¶
Skills 适合沉淀可复用的操作说明、轻量工作流、局部工具使用方法，但不适合承载企业级核心能力。
原因包括：
- 业务能力主要应该由代码、API、权限系统和数据契约保证，而不是靠提示词约束。
- 企业流程通常涉及多系统读写、审批、状态流转、审计追踪，skills 很难可靠承载。
- 高质量交付需要评测、回归、日志、权限隔离和失败恢复，这些都属于 harness 层能力。
所以 skills 可以作为外层说明或辅助入口，但不应该成为工程主体。
为什么不是只做 hooks¶
Hooks 适合做拦截、审计和治理，例如：
- 工具调用前做权限检查。
- 检测 prompt 是否包含敏感信息。
- 工具执行后记录审计日志。
- 回合结束时做质量校验。
- 根据目录或项目注入局部约束。
但 hooks 不适合承载复杂业务流程，例如 HR 入职办理、财务报销审核、研发需求到 PR 的交付链路。
更准确的定位是：
Hooks 是保险丝和传感器，不是业务发动机。
推荐方向¶
企业 harness 应该具备以下几层能力：
text
企业 Agent Harness
├─ Runtime Adapter: Claude Agent SDK / Codex SDK / OpenAI Agents SDK / 其他模型
├─ Tool Plane: MCP servers + function tools + 内部系统 API
├─ Context Plane: 制度、流程、知识库、代码库、财务/HR/OA 数据
├─ Policy Plane: 权限、审批、脱敏、审计、风控
├─ Workflow Plane: 多步骤任务编排、状态机、人工确认
├─ Eval Plane: 回归集、红队测试、质量评分、成本/延迟监控
└─ UI/API: 给 HR、行政、研发、财务等部门使用的入口
在当前阶段，UI/API 不只是辅助入口，而是 AI 平权的核心承载层。面向不擅长配置和使用底层 AI 工具的员工，系统必须提供网页端任务工作台和企业微信入口，把复杂的 Codex、Claude Code、SDK、网络环境、订阅和工具接入问题统一封装在后端。
第一批切入点¶
第一批场景优先选择三个部门：
- 研发部门：适合验证 issue、代码修改、测试、PR、CI 和研发知识库工作流。
- 市场营销部门：适合验证资料整理、内容生产、竞品分析、活动方案和营销复盘。
- 职能管理服务部门：覆盖 HR、行政、财务、后勤、采购、法务等流程密集场景。
选择这些部门，是因为它们同时具备高频任务、文档密集、跨系统协作和可沉淀 workflow 的特点。
两类交互¶
产品需要同时处理两类交互。
第一类是人与 Agent 的交互：
- 员工通过 Web、企业微信和业务系统入口发起任务。
- UI 承接自然语言、文件、表单、审批和业务动作。
- 后端 harness 调用 SDK、runtime adapter 和 tool plane 完成服务。
第二类是 Agent 与 Agent 的交互：
- 不同 agent 以事件、命令、查询和产物方式协作。
- Agent 组织结构会影响企业内部人的组织关系。
- 未来组织沟通会从“人找人同步”更多转向“人找 agent，agent 找 agent 协作”。
因此，harness 既是员工入口，也是组织协作网络。
不建议依赖泄露源码¶
不应把方案建立在泄露源码上。
主要风险：
- 法律和合规风险高。
- 客户公司难以接受。
- 无法稳定跟随官方升级。
- 容易形成不可维护的 fork。
更稳妥的路线是使用官方 SDK、CLI、API、MCP、hooks、plugins 等扩展边界，再通过 adapter 抽象隔离具体 provider。
产品化目标¶
最终交付物应该是一套可部署、可审计、可扩展的企业智能体平台，而不是一次性 demo。
衡量标准：
- 能接入公司内部真实系统。
- 能控制不同角色的操作权限。
- 能记录每次 agent 决策和工具调用。
- 能在人类审批点暂停。
- 能对关键任务跑回归评测。
- 能替换底层模型或 agent runtime。
- 能让不同部门按任务族复用能力。
进一步看，内部实践成熟后，平台还应该能沉淀为外部可销售的方案包：把内部成功 workflow、工具、模板、培训和评测转化为面向外部小组织的智能体解决方案。