我组建了一个虚拟产研团队，7个成员全是 AI

AI在软件开发中已从辅助编码延伸至项目管理。Harness Engineering提出构建类团队的AI协作系统Cowork Forge正是该理念实践通过分工明确的AI代理完成需求到交付全流程实现高效人机协同让开发者聚焦更高阶决策。当 AI 开始像一个真实团队一样协作软件开发的方式正在被重新定义。一、一个产品经理的深夜凌晨一点小张还在公司加班。小张作为产品经理刚把「任务模块」的需求初稿交给研发就知道后面的路并不轻松要反复打磨 PRD、对齐模糊需求参与技术评审来回沟通修改方案需求临时调整还要及时同步前后端与测试。上线前更要全程跟进联调、测试与 bug 修复像总指挥一样在各个环节来回协调不敢有半点松懈。他也尝试过 AI开发工具编码效率确实有所提升但无法支撑从需求落地、方案设计的完整流程。大量繁琐的沟通、对齐与推进工作最终还是要小张和团队亲自扛下来问题到底出在哪里小张的经历不是个例。即使有了 AI 编程助手大多数开发者的工作方式并没有本质改变。我们仍然在扮演项目经理的角色协调各个阶段的工作确保信息不丢失、决策不矛盾、进度不偏离。AI 可以帮我们写代码但 AI 帮不了我们做项目。这让我想起一个比喻AI 编程工具就像是给建筑师配了一个特别厉害的画图员——他画图很快但建筑该怎么设计、结构该怎么布置、材料该怎么选这些决策还是要建筑师自己来做。如果有一个工具能帮我们做项目而不仅仅是写代码呢二、AI 编程工具的最后一公里在过去两年里AI 编程领域经历了爆发式增长。GitHub Copilot 从新奇玩具变成了许多开发者的标配Cursor 等 AI 原生编辑器也在快速迭代。但如果你问这些工具的用户一个简单的问题从你有一个想法到它变成可运行的代码中间还需要你做什么答案往往是很多。你仍然需要把想法整理成需求文档仍然需要做技术设计仍然需要规划任务优先级仍然需要协调各个环节的依赖关系。AI 工具只在编码这个环节帮了忙但编码只是软件开发的一小部分。这不是工具的能力问题而是架构范式问题。让我们用一个表格来看看传统 AI 工具和真实开发需求之间的差距这就好比让一个全能运动员去踢整场足球赛——他可以踢前锋、中场、后卫甚至守门员但他无法同时出现在所有位置。足球比赛的复杂度需要的是专业化分工而非全能化堆砌。同理产品经理需要用户视角和商业思维架构师需要系统思维和技术深度工程师需要实现细节和编码能力。这些是不同的思维模式很难在一个模型中同时达到最优。我们需要一种新的架构范式。三、Harness Engineering让 AI 像团队一样工作在 AI 工程领域有一个越来越受关注的概念叫Harness Engineering。它的核心思想是与其追求一个超级模型不如构建一个超级编排系统——通过结构化的任务分解、角色分工和流程编排让多个专业化组件协同完成端到端的复杂工作。这不是什么全新的发明。在人类组织中我们早就用这种方式解决复杂问题公司有部门分工项目有角色分工流水线有工序分工。Harness Engineering 只是把同样的智慧应用到了 AI 系统设计中。传统 AI 工具 vs Harness 架构在 Harness 架构下每个 Agent 扮演一个专业角色有自己的职责范围和工具箱。编排器负责任务的流转、上下文的传递、以及人机协作的协调。这就像是组建了一个虚拟团队有产品经理、架构师、工程师、测试工程师……他们各司其职但共享同一个项目上下文协同完成从想法到交付的全过程。但这带来一个关键问题这个团队该怎么协作软件开发不是流水线——需求可能在编码阶段发现漏洞设计可能在测试阶段证明不可行。如果只是简单的传递模式信息会在传递中失真问题会在延迟中被放大。我们需要的不只是分工还需要反馈。四、Cowork Forge一个真实的实践样本带着上面的问题我们来看一个具体的实践 —— Cowork Forge。Cowork Forge 是一个开源的 AI 多智能体协作平台。用 Harness Engineering 的理念提供由AI驱动的从想法到代码端到端解决方案。在深入技术细节之前让我们先看一个真实的场景。4.1 硅基团队带着你跑完整个项目。假设我是一个产品经理我想做一个任务管理 API。我对 Cowork Forge 说我想做一个任务管理的 REST API支持创建任务、更新任务状态、查询任务列表。首先系统进入了需求采集阶段。一个需求 Agent开始和我对话确认细节任务需要哪些字段状态有哪些取值需要用户认证吗几轮对话后它生成了一份结构化的需求规格文档并暂停等待我确认。确认后系统自动进入PRD 生成阶段。这次是一个产品 Agent在工作它基于需求规格生成了一份完整的产品需求文档——包括功能描述、用户故事、非功能需求、边界条件处理。同样生成完毕后暂停等我确认。然后是架构设计阶段。架构 Agent登场了。它分析了需求选择了技术栈Axum Turso设计了数据模型和 API 接口输出技术设计文档生成架构图。接下来是实施计划阶段、编码阶段、检查阶段、交付阶段。每个阶段都有专门的 Agent 在工作每个关键节点都有人工确认的门。7位数字牛马团结协作产品Agent的创意IDEA产品Agent的Features PRD设计Agent给的设计规范最终我得到了完整的PRD 文档、技术设计文档、实施计划、可运行的代码、测试报告、交付Showcase。整个过程中我只做了两件事提供了最初的想法以及在几个关键节点做反馈。这和常用的基于CLI/IDE的AI开发工具体验完全不同。前者 帮我写代码但 Cowork Forge 帮我做项目。4.2 核心架构设计让我们剥开表象看看 Cowork Forge 的架构设计。整体架构工作流程低分辨率工作流程高分辨率核心设计有三个关键点第一专业化分工。每个阶段由专门的 Agent 负责有自己的指令集和工具集。需求 Agent 擅长澄清模糊需求设计 Agent 懂得架构权衡编码 Agent 熟悉代码实现。这种专业化确保了每个环节的输出质量。第二Actor-Critic 模式。这是 Cowork Forge 最有意思的设计之一。每个阶段不是生成即结束而是生成 → 审查 → 迭代。具体来说当一个 Actor Agent 完成生成后会有一个 Critic Agent 来审查输出。Critic 会检查需求是否遗漏设计是否合理代码是否有明显 bug如果发现问题会触发重新生成并附带具体的改进建议。这就像是每个角色都有一个影子搭档负责挑刺和改进。这种设计大大提高了输出的可靠性。第三人在回路HITL。虽然有了 Actor-Critic 模式Cowork Forge 仍然在关键决策点保留了人工确认的门。为什么因为有些决策是 AI 无法代替的——比如产品方向的取舍、架构方案的选择、关键实现的确认。AI 可以执行但人类负责方向。这是一种监督式自主而非完全自主。它追求的不是无人值守而是人机协同最优。4.3 可定制的团队配置一个有趣的问题是如果每个团队的开发流程都不一样这套系统能适配吗Cowork Forge 的答案是配置驱动而非代码硬编码。系统引入了三层可定制机制Flow 定制开发流程本身可以定义。默认的七阶段流程适合大多数项目但你可以创建自己的流程模板——比如快速原型流程只包含需求、设计、编码、交付四个阶段企业级流程可能在设计之后增加一个安全审查阶段。流程配置以 JSON 格式定义无需修改代码。Agent 角色编辑每个 Agent 的人设可以调整。你可以修改 Agent 的指令模板、调整其使用的工具集、甚至指定不同的模型参数比如让编码 Agent 用更强的推理模型。这让 Agent 能够适配团队的编码规范和技术偏好。兼容Skill生态兼容skill.io的SKILL标准它可以注入额外的工具、提示模板和上下文知识。比如你可以导入一个React 开发技能包里面包含了 React 组件的最佳实践、常用工具函数、项目模板等。Skill 基于 agentskills.io 标准支持从本地目录或远程仓库导入。这种设计的核心思想是把怎么工作的控制权还给用户。系统提供了合理的默认值但不强制你接受。你可以根据团队的习惯、项目的特点、技术的偏好来调整——就像你可以根据项目需要调整真实团队的分工和流程一样。4.4 Memory多 Agent 协调的共享大脑在多 Agent 系统中有一个核心挑战Agent 之间如何共享记忆这不是简单的存储问题。想象一个真实团队产品经理做的决策工程师需要知道架构师的技术选型测试工程师需要理解上一个迭代的踩坑经验下一个迭代需要规避。这些共享记忆是团队协作的基础。在 Agent 工程化领域这被称为Memory 系统——它承载了多 Agent 协调所需的各种记忆形态Feedback 记忆用户在某个阶段给出的反馈这个设计太复杂了、这个接口命名不清晰会被记录并传递到后续阶段。当编码 Agent 工作时它会记得用户对设计的偏好避免重蹈覆辙。环境上下文记忆项目的技术环境——语言、框架、数据库、依赖版本——会被自动检测并注入到每个 Agent 的上下文中。这确保了所有 Agent 都在同一个世界里工作不会出现设计 Agent 选了 PostgreSQL编码 Agent 却按 MySQL 写 SQL 的情况。项目知识记忆这是跨迭代的知识沉淀。架构决策及其理由、设计模式的使用场景、已知问题及规避方法……这些会被自动提取并持久化存储。当你三个月后回来继续开发系统仍然记得当初为什么选择这个技术栈、有哪些坑需要避开。迭代知识记忆每次迭代结束后系统会自动生成本次迭代的知识快照——包括实现的功能、遇到的问题、解决的方法、遗留的技术债务。这些知识会成为下一次迭代的起点。更厉害的是Cowork Forge 具备项目 Codebase 级知识自动生成能力。系统会分析整个代码库的结构、模块划分、关键算法、数据流向自动生成一份代码地图。这份知识不是简单的代码注释而是对整个项目的结构化理解——当你问这个项目的认证模块在哪里系统能直接告诉你答案。Cowork Forge 知识架构项目级认知 (Codebase Knowledge)经验记忆 (Iteration Memory)这是真正的项目级AI而非会话级AI。4.5 开放的 Agent 生态外挂你喜欢的Coding Agent在软件开发领域有一件事是确定的每个开发者都有自己的偏好。有人习惯用 Claude Code 的深度推理有人喜欢 OpenAI Codex 的多模态能力有人偏爱 Code Flicker 的流畅体验还有人对某个小众工具情有独钟。这些工具各有特色没有哪个能在所有场景下都称得上最佳。那么问题来了如果 Cowork Forge 的编码阶段只能用内置的 Coding Agent开发者岂不是被绑定了这正是 Cowork Forge 在设计时重点考虑的问题。Cowork Forge自身实现了Built-in Coding Agent同时也兼容 ACP (Agent Client Protocol) 协议这是一个由JetBrains和Zed Industries发起的行业标准协议业内几乎所有主流Coding Agent都支持让 Cowork Forge 能够外接任何支持该协议的 Coding Agent 工具。具体来说编码阶段的执行逻辑是这样的Cowork Forge 不试图取代你习惯的工具而是做一个编排者——它负责流程调度、上下文管理、知识沉淀、结果验证而具体的编码工作可以交给你最顺手的工具来完成。五、与现有工具的差异聊到这里你可能会问这和 GitHub Copilot、Cursor 有什么区别让我用一个比喻来说明Copilot 是副驾驶你需要自己开飞机。它能帮你操作一些控制提醒你注意仪表盘甚至在你疲惫时接手一会儿。但航线是你定的飞行计划是你做的遇到突发情况还是得你来决策。Cowork Forge 是自动驾驶系统你只需设定目的地。它会自己规划航线、检查天气、计算油耗、调整高度。你只需要在起飞前确认计划飞行中偶尔监控降落时验收结果。当然如果遇到特殊情况你随时可以接管。更准确地说它们不是竞争关系而是互补关系。Copilot 帮你在微观层面提升效率Cowork Forge 帮你在宏观层面解放生产力。理想的工作流可能是用 Cowork Forge 完成项目的框架搭建和文档生成再用 Copilot 在日常编码中提升效率。六、项目导入即能让旧项目开口说话也是项目重构/逆向移植的利刃如果你手头有一个已经存在的项目——可能是半年前做的可能是别人交接的甚至可能不是用 Cowork Forge 创建的——系统能帮上忙吗答案是可以。Cowork Forge 提供了一个强大的项目导入与逆向分析功能。它能够对任意现有项目进行逆向工程自动生成高保真的需求文档和技术设计方案。具体来说当你导入一个项目后系统会第一步项目扫描与检测系统会分析目录结构、配置文件package.json、Cargo.toml、requirements.txt 等、依赖关系自动识别技术栈和项目类型。它还会读取 README、现有文档、关键源文件建立对项目的初步认知。第二步逆向分析接下来系统会调用一个专门的项目分析 Agent基于扫描到的信息进行深层次的逆向推理这个项目的原始需求是什么解决了什么问题项目的技术架构是如何设计的为什么这样设计有哪些功能模块它们之间如何协作有哪些技术债务和已知问题第三步文档生成最终系统会生成四份核心文档文档内容idea.md项目概述、背景动机、核心功能、目标用户prd.md功能需求详情、非功能需求、约束条件design.md技术架构、模块设计、数据模型、接口定义plan.md当前实现状态、后续规划、待完成事项这个功能的价值在于让沉默的代码开口说话。对于那些文档缺失、交接不完整的项目这是快速建立认知的利器。对于那些想将现有项目纳入 Cowork Forge 工作流的团队这是无缝迁移的入口。七、自适应项目启动与实时预览软件开发不只是写代码还包括跑起来看效果。Cowork Forge 在这方面也有独到的设计智能项目运行与实时预览。当你完成编码阶段后系统可以自动启动项目并预览运行效果。但这里有一个挑战不同项目的运行方式差异巨大—— React 项目用 bun run devRust 项目用 cargo runPython Flask 项目用 python app.py……系统怎么知道该怎么跑答案是大模型智能识别。系统会分析项目的技术栈自动推断正确的启动命令。它会读取 package.json 的 scripts 字段解析 Cargo.toml 的配置检查常见的入口文件……然后生成一个运行计划。更聪明的是系统还能根据运行过程中的反馈进行动态调整。比如第一次启动失败了系统会分析错误日志判断是依赖没装还是端口冲突然后尝试修复并重新启动。运行状态的可视化系统内置了一个实时的日志查看器你可以看到启动命令和参数实时的 stdout/stderr 输出运行状态启动中、运行中、已停止错误提示和诊断建议对于 Web 项目系统还提供了内置的应用预览——一个嵌入式的浏览器视图让你无需切换窗口就能看到运行效果。这看起来是一个小功能但它体现了 Cowork Forge 的理念端到端不只是从想法到代码而是从想法到可运行的应用。八、挑战与思考当然这种模式也面临不少挑战。第一个挑战是上下文窗口。一个真实项目的上下文可能非常庞大——需求文档、设计文档、代码库、历史决策……要把这些全部塞进 LLM 的上下文窗口目前仍有技术瓶颈。Cowork Forge 的解决方案是智能裁剪——通过向量检索和关键词匹配只把与当前任务相关的上下文注入模型。同时Memory 系统会将项目知识结构化存储避免每次都传递原始文档。这是一种权衡在大多数场景下有效但在极端复杂的项目中可能仍有信息丢失。第二个挑战是 Agent 协调。多个 Agent 如何保持输出的一致性如果设计 Agent 选择了一个架构方案但编码 Agent 发现无法实现该怎么处理Cowork Forge 通过Memory 共享和Actor-Critic 模式来缓解这个问题。所有 Agent 都能访问同一份项目知识减少了信息不对称。Critic 机制则提供了跨阶段校验的能力。但完美的协调仍然是一个开放的研究课题。第三个挑战是安全性。让 AI 执行命令、修改文件本身就带有风险。如果 AI 生成了一个危险的命令怎么办Cowork Forge 实现了多层安全机制命令白名单、路径访问控制、工作区隔离、危险操作检测。系统会阻止 rm -rf、sudo 等高危命令确保所有文件操作都在指定的工作区范围内。但这仍然是一个需要持续关注的领域。设计哲学不是追求完全自主而是追求人机协同最优。关键决策保留给人类执行交给 AI。这既是对当前技术能力的清醒认识也是对软件开发本质的尊重——有些决策本就该由人来拍板。九、一人即团队回到文章开头小张的故事。如果他用了 Cowork Forge那个凌晨一点的加班可能就不会发生。他只需要说我想做一个用户任务管理模块系统就会帮他完成从需求到代码的全部工作——甚至还包括运行预览。他要做的是在关键节点确认方向而不是在每个细节上消耗精力。一人即团队这不再是一个口号而是正在发生的现实。当然Cowork Forge 不是银弹。它有其适用范围和局限性。但它代表了一种新的可能性——一种让 AI 真正成为生产力解放者而非代码生成器的可能性。如果你对 Harness Engineering、多智能体协作、人机协同设计感兴趣不妨看看这个项目。它是开源的代码在 GitHub 上欢迎Star和PR。项目地址https://github.com/sopaco/cowork-forge写在最后AI 正在改变软件开发。但真正的变革不是AI 写代码而是AI 做项目。当 AI 开始像一个真实团队一样协作开发者的角色也在悄然转变——从执行者变成导演从写代码变成定方向。未来即至。