2个Agent协作：一位开发者如何用2天完成知识库白标改造的需求设计
一位专注软件产品定制的开发者连续2天使用 OpenAgents（4个 Session、301个事件），配置2个 Agent：Claude Opus 4.8 担任产品经理，负责调研现有系统并编写改造需求；Codex 担任开发工程师，负责按文档修改代码。目标是对 WeKnora 知识库管理系统进行白标改造——在保留核心知识库功能的前提下全面替换品牌视觉和标识。
背景
白标改造技术难度不高，难在协调：Logo、产品名称、配色方案、包名、域名、第三方品牌集成……改造点散落在前端页面、配置文件、代码变量和第三方服务中。把『改什么』梳理清楚、写成可执行文档、交给开发，这个流程对单人开发者协调成本很高。
核心痛点
白标改造涉及面广，容易遗漏
改造点散落在前端页面、配置文件、代码变量和第三方服务中，人工梳理很难一次性覆盖完整。
需求文档编写耗时
将所有改造点整理成可供开发直接执行的文档，需要逐页分析系统、逐个模块确认。
从需求到开发的交接容易信息丢失
需求文档写完后，开发人员需要重新理解业务目标和改造范围，中间环节多、沟通成本高。
改造与核心功能之间的边界不清晰
白标改造不能影响知识库核心功能，哪些能改、哪些需要保留，需要产品经理先做好判断。
落地过程
第一阶段：产品经理Agent梳理需求（第1天）
用户向 Claude（产品经理 Agent）提出目标：替换 Logo、产品名称、配色、包名和域名，删除不需要的第三方品牌集成，保留核心知识库功能。Claude 逐页分析现有系统、整理改造范围，最终生成《WeKnora 换皮需求设计》文档，明确了所有修改点——用户只需提出目标并审核输出。
第二阶段：开发Agent接手与交接（第2天）
Codex（开发 Agent）接收需求文档，理解改造范围和优先级，准备执行具体的代码替换——验证了『产品经理写需求、开发接需求』的真实研发流程在 Agent 之间可行。此后因 Windows 命令启动错误，开发环节暂停在需求阶段；但从需求分析到开发交接的流程已完整验证，这份文档也可继续交由其他开发人员或开发 Agent 执行。
工作空间实景
实际效果
白标改造范围从『零散想法』变成『结构化需求文档』
换 Logo、改名字、调颜色、删集成等零散需求被系统化整理成完整文档，改造点按模块分类、边界清晰，可直接作为开发依据。
Agent 角色分工模拟了真实研发团队
Claude 负责需求分析和文档产出，Codex 负责代码执行，协作流程与真实软件团队的『产品经理→开发工程师』交接一致。
需求到开发的交接链路已验证
需求文档从产品经理 Agent 传递到开发 Agent 的过程顺畅，说明不同角色的 Agent 可以基于文档进行任务交接，为同类项目提供可复制的工作流。
核心功能与白标改造的边界被明确区分
产品经理 Agent 将『必须保留的核心功能』和『可以替换的品牌元素』清晰划分，避免改造过程中误删核心功能。
结语
2天内，一位开发者借助2个角色分明的 Agent 完成了从改造目标提出到需求文档产出、再到开发交接的完整流程。个人开发者不需要同时扮演产品经理和开发工程师——一个 Agent 负责将业务目标形成结构化需求，另一个按文档执行技术实现；即使开发环节因外部环境受阻，这份已验证的需求文档依然是可移交的成果。
