决策记录¶
本页记录关键架构判断。每条决策都应该包含背景、选择、理由和后续影响。
ADR-001：项目定位为 Agent Harness，而不是 Skills 集合¶
日期：2026-06-10
背景¶
我们希望基于 Claude Code、Codex、OpenAI Agents SDK 等成熟智能体框架，为公司 HR、行政、研发服务、财务、后勤等部门开发智能体工程。
决策¶
项目定位为企业级 Agent Harness / Agent Operating Platform，而不是一组 prompts、skills 或简单 hooks。
理由¶
- 企业能力需要工具、权限、审批、审计、评测共同保证。
- Skills 适合辅助说明，不适合承载核心业务流程。
- Hooks 适合治理和拦截，不适合承载复杂流程。
- Harness 可以让底层 runtime 随技术演进替换。
影响¶
后续优先建设：
- Runtime Adapter。
- Tool Plane。
- Workflow Plane。
- Policy Plane。
- Eval Plane。
ADR-002：不依赖泄露源码¶
日期：2026-06-10
背景¶
一种设想是基于 Claude Code、Codex 等的 SDK，或使用泄露源码等方式进行二次开发。
决策¶
不把技术方案建立在泄露源码上。
理由¶
- 法律和合规风险高。
- 客户公司难以接受。
- 难以稳定跟随官方升级。
- 供应链安全风险不可控。
影响¶
后续只使用官方 SDK、CLI、API、MCP、hooks、plugins 等可接受扩展边界。
ADR-003：企业协同入口优先支持企业微信¶
日期：2026-06-10
背景¶
目标企业主要使用企业微信作为组织通讯、通知、审批和内部应用入口，而不是飞书。
决策¶
后续入口设计、通知能力、身份同步、审批联动和工具接入优先围绕企业微信展开。
理由¶
- 贴合目标企业现有工作流。
- 减少用户切换成本。
- 企业微信通讯录、群聊、应用消息和审批能力可作为 agent 触达用户与请求确认的关键通道。
影响¶
后续需要补充：
- 企业微信应用接入方案。
- 通讯录和组织架构同步方案。
- 群聊上下文获取边界。
- 审批和人工确认消息设计。
- 企业微信回调事件与 harness workflow 的映射。
ADR-004：产品叙事从工具提效升级为组织变革¶
日期：2026-06-10
背景¶
随着大模型和底层 agent harness 能力增强，组织使用 AI 的方式会从个人工具试用转向组织级生产系统重构。尤其是几百人以下的小组织，更容易通过 agent harness 改造组织结构和运转方式。
决策¶
产品底层叙事升级为：通过企业 Agent Harness 实现 AI 平权、组织结构重构和生产力再配置，并将内部成功经验沉淀为可对外输出的智能体解决方案。
理由¶
- 单点提效工具壁垒较低，容易被底层模型和通用 agent 框架吞噬。
- 组织级 harness 能沉淀流程、权限、工具、审计和评测，形成长期资产。
- AI 平权可以充分动员一线员工，释放真实业务问题和改造机会。
- 释放出来的人力、资金和知识可以被重新配置到培训、交付和外部方案业务。
表达边界¶
内部可以使用“广泛动员 + 强组织执行”作为战略类比。对外客户沟通中，应转译为商业和组织设计语言，避免政治化表达影响销售、合规和品牌接受度。
影响¶
后续产品设计需要同时覆盖：
- 员工入口。
- 组织运行看板。
- workflow 和工具沉淀。
- 培训转化体系。
- 标杆案例复制。
- 外部客户交付方法论。
ADR-005：第一批切入研发、市场和职能管理服务部门¶
日期：2026-06-10
背景¶
企业 Agent Harness 需要从真实高频场景切入，不能停留在抽象平台建设。第一批场景既要能证明内部降本增效，也要能沉淀为外部可复制方案。
决策¶
第一批切入部门为研发部门、市场营销部门和职能管理服务部门。
理由¶
- 研发部门适合验证 Codex、Claude Code 等代码 agent 能力，且有测试、PR、CI 等客观验证闭环。
- 市场营销部门内容和资料密集，适合快速体现 AI 对执行效率和输出质量的提升。
- 职能管理服务部门流程多、审批多、文档多，是组织运行成本集中区域。
影响¶
后续样板 workflow 优先选择：
- 研发：Issue 到 PR。
- 市场：资料到内容包。
- 职能：员工请求到工单/审批。
ADR-006：Web 任务工作台和企业微信是 AI 平权入口¶
日期：2026-06-10
背景¶
多数部门员工并不熟悉 Codex、Claude Code、SDK、API key、网络环境、海外订阅和工具配置。如果要求员工自己掌握这些，AI 能力会集中在少数技术人员手中，无法实现组织级平权。
决策¶
产品必须提供网页端任务工作台，并优先接入企业微信作为轻量入口、通知和审批通道。底层模型、runtime、工具、权限和网络复杂度由后端 harness 封装。
理由¶
- 员工使用门槛最低。
- 能承接自然语言、文件、表单、审批和业务控件。
- 符合目标企业现有协同习惯。
- 便于后端统一做权限、审计、评测和成本控制。
影响¶
后续前端不能只做聊天壳，而要设计任务工作台：
- 对话区。
- 文件空间。
- 业务控件。
- 任务状态。
- 审批确认。
- 证据和审计摘要。
ADR-007：Agent-to-Agent 网络参考 Zenoh 思想，但第一阶段先做逻辑 Agent Bus¶
日期：2026-06-10
背景¶
未来组织协作不只是人与 agent 的交互，还会出现 agent 与 agent 的协作。Agent 的组织结构会影响人的组织结构关系。
决策¶
Agent-to-Agent 通信参考 Zenoh 一类系统的思想，采用事件、命令、查询和产物传递的抽象。但第一阶段不强依赖 Zenoh，先在后端实现逻辑 Agent Bus。
理由¶
- 避免把所有 agent 写成点对点耦合接口。
- 支持部门 agent、专业 agent 和治理 agent 松耦合协作。
- 降低第一阶段基础设施复杂度。
- 保留后续迁移到 Zenoh、NATS、Kafka、Redis Streams 等基础设施的空间。
影响¶
后续需要定义：
- agent 命名和职责边界。
- message schema。
- event / command / query / artifact 类型。
- trace 和审计字段。
- 循环调用和冲突检测。
ADR-008：采用 Obsidian + GitHub 的团队知识库路线¶
日期：2026-06-10
背景¶
团队希望采用类似 Karpathy LLM Wiki 的方法，把微信群讨论、项目材料、网页资料、会议纪要和 Agent 输出沉淀为持续演化的团队知识库。团队规模约五六人，成员都是 AI 原生工程师。
决策¶
采用 Obsidian 作为团队知识库 IDE，GitHub 作为版本协作底座，MkDocs/Cloudflare Pages 作为正式教程发布渠道。
理由¶
- Obsidian 基于 Markdown 文件，适合 Agent 直接读写。
- GitHub 提供 PR、review、历史版本和多人协作。
- Karpathy LLM Wiki 方法强调 raw sources、wiki、schema、index、log，和当前工程化文档方式高度兼容。
- 团队是 AI 原生工程师，可以接受 Git 工作流。
影响¶
后续需要建立：
- team-vault 目录结构。
- ingest/query/lint/publish 四类 Agent 工作流。
- raw source 不可变规则。
- wiki 编译日志。
- 从 Obsidian 到 MkDocs 的发布流程。
ADR-009：项目升级为组织级 Agentic Knowledge Infrastructure¶
日期：2026-06-11
背景¶
当前 Harness 已经具备团队知识工程、MkDocs 文档站和 Obsidian vault 的基础。下一阶段需要从企业 Agent Harness 文档底座升级为组织级 Agentic Knowledge Infrastructure，并准备迁移到 VariAI/OrgReOrg 团队仓库。
参考 /home/ai/workspace/data_engineering 的私域搜索系统，组织知识能力不应停留在静态文档和聊天记录整理，而应支持文档解析、BM25 / 向量混合检索、Rerank、MCP 工具、Agentic Search、多轮阅读、证据引用和知识缺口识别。
决策¶
将项目定位升级为 OrgReOrg / Harness：组织级 Agentic Knowledge Infrastructure。
系统以企业微信、飞书和 Web 工作台作为统一交互入口，但不局限于聊天数据；通过 Agentic Search、主动信息收集、部门系统 Connector、MCP 工具层、权限化上下文视图和 Loop Engineering，把分散在 GitHub、财务系统、CRM、项目管理系统、文档系统、BI 等业务系统中的组织信息，持续转化为可检索、可调用、可授权、可审计的私域智能能力。
理由¶
- 企业微信和飞书适合做人机入口、通知、身份和审批确认，但不是完整业务数据源。
- 真实业务信息分散在部门业务系统中，必须通过 Connector 和权限化工具接入。
- Agentic Search 比一次性 RAG 更适合复杂组织问题，因为它支持多轮检索、深度阅读、交叉验证和缺口识别。
- 权限化上下文视图可以把统一知识与业务数据按用户、部门、项目、角色和任务裁剪给 Agent。
- Loop Engineering 可以把搜索、收集、权限和知识维护从隐式聊天行为变成可设计、可验证、可审计的工程循环。
影响¶
后续优先建设：
- 私域 Agentic Search 原型。
- 主动信息收集机制。
- Connector registry 和 MCP Tool Gateway。
- Permissioned Views / MVC 权限模型。
- Search Loop、Collection Loop、Permission Loop、Knowledge Maintenance Loop。
- 面向新仓库
OrgReOrg的 README、导航和路线图。
ADR-010：MVP 先跑通企微入口与主动收集¶
日期：2026-06-12
背景¶
OrgReOrg 的近期技术路线包含企业微信入口、Agentic Search、主动信息收集、知识外挂和 MVC 权限模型。当前阶段团队规模小，最重要的是先跑通真实任务闭环，验证智能体如何从已有知识搜索、发现缺口、主动询问相关人，并把补充信息沉淀为可复用知识。
决策¶
MVP 阶段优先建设：
- 企业微信入口和通知。
- 最小 Agentic Search。
- 知识缺口识别。
- 主动询问相关人。
- 补充信息以
knowledge_card形式挂载到任务，再经 review 进入 vault 或 docs。
完整 MVC 权限模型不作为 MVP 前置条件，只保留最小只读、审计和高风险动作人工确认边界。
理由¶
- 企业微信是目标用户已有工作入口，能最快验证人机协同。
- 主动询问和“问谁”路由是产品创新点，应尽早验证。
- 补充信息来源复杂，先用 knowledge card 和 review 状态比一开始建复杂数据库更稳。
- 完整 MVC 权限模型需要真实数据对象、工具调用和审计记录作为输入，过早实现容易抽象失真。
影响¶
近期开发计划按企业微信 POC、最小搜索、主动询问、知识外挂、最小治理推进。后续出现跨部门、跨项目或敏感字段需求后，再启动完整 MVC 权限模型实现。