EchoAgent 多 AI 协同系统设计文档

1. 一句话目标

EchoAgent 是一个多 AI 协同编排系统：用户输入一个目标后，产品经理 Agent 负责持续判断目标是否达成；如果未达成，Orchestrator 会继续调度技术 Leader Agent、工程师 Agent、测试 Agent 进入下一轮，直到目标达成或遇到必须由用户决策的阻塞点。

核心不是“多个 AI 分别回答问题”，而是让多个 AI 像一个小团队一样围绕同一个目标持续协作。

2. 要解决的问题

用户现在想解决的问题是：

• 用户只想输入一个目标，不想每一步都手动追问。
• 产品经理 Agent 要承担目标负责人角色，持续检查目标是否完成。
• 如果目标没有完成，系统要自动推动下一轮，而不是停在那里等用户问“为什么还没跑通”。
• 多个 AI 的工作状态要可见，用户能看到谁在做什么。
• 产品经理下发的指令要有清晰流动路线，能看到命令如何经过技术 Leader、工程师、测试，再回到产品经理复核。

因此 EchoAgent 第一版的重点是：

• 多 Agent 协同。
• HTTP Orchestrator。
• 自动目标跟进。
• Web 状态全览。
• 消息和命令流转可视化。

3. 核心原则

• 目标驱动：系统围绕用户输入的目标运转，而不是围绕单次对话运转。
• 产品经理负责闭环：产品经理 Agent 不只是写 PRD，还要持续判断目标是否达成。
• 默认自动推进：目标未达成时，系统自动创建下一轮任务。
• 用户只在必要节点介入：目标变更、高风险工具调用、权限授权、关键信息缺失时才打断用户。
• 所有过程可见：Web 页面展示 Agent 状态、任务阶段、消息路线和迭代历史。
• 所有动作可追踪：每条命令、每次工具调用、每个测试结果都要有记录。
• 先实现最小闭环，再扩展能力：第一版先跑通协同链路，不急着做复杂模型路由、向量库和分布式部署。

4. 总体架构

第一版采用本地 HTTP 服务作为 Orchestrator。不同 cmd 中启动的 Codex 会话或其他 AI Worker 都连接到同一个 HTTP 服务。

用户
 |
 | 输入目标
 v
Web 页面 / CLI
 |
 v
EchoAgent HTTP Orchestrator
 |
 +-- Product Manager Agent Worker
 +-- Tech Leader Agent Worker
 +-- Engineer Agent Worker
 +-- Tester Agent Worker
 |
 +-- Tool Adapter Layer
 |     +-- 文件系统
 |     +-- Shell 命令
 |     +-- Git
 |     +-- 测试命令
 |     +-- 浏览器或其他工具
 |
 +-- Storage
 |     +-- tasks
 |     +-- agents
 |     +-- messages
 |     +-- command_routes
 |     +-- events
 |     +-- tool_calls
 |     +-- artifacts
 |
 +-- Web Dashboard
       +-- Agent 状态
       +-- 任务阶段
       +-- 命令流动路线
       +-- 时间线
       +-- 阻塞点

5. 核心组件

5.1 Orchestrator

Orchestrator 是系统中枢，负责接收目标、分配任务、维护状态、记录事件、调度下一轮。

职责：

• 接收用户创建的目标。
• 创建任务和迭代轮次。
• 注册和管理 Agent Worker。
• 根据工作流给 Agent 分配任务。
• 接收 Agent 执行结果。
• 维护全局上下文。
• 记录消息、命令路线、工具调用和事件。
• 判断是否需要继续迭代。
• 在必要时请求用户介入。

5.2 Product Manager Agent

产品经理 Agent 是目标负责人。

职责：

• 理解用户目标。
• 输出目标说明、用户场景、功能范围、优先级。
• 定义验收标准。
• 下发产品指令。
• 持续检查测试结果和实现结果。
• 判断目标是否达成。
• 未达成时，明确差距并推动下一轮。
• 只有在目标不清楚、目标变化或需要用户决策时请求用户介入。

典型输出：

• 产品目标说明。
• PRD。
• 验收标准。
• 产品指令。
• 目标达成判断。
• 下一轮跟进任务。

5.3 Tech Leader Agent

技术 Leader Agent 负责把产品目标转成技术路线。

职责：

• 读取产品经理的目标和验收标准。
• 设计技术架构。
• 拆分模块。
• 定义接口、数据结构和实现顺序。
• 识别技术风险。
• 给工程师 Agent 下发实现任务。
• 根据测试反馈调整技术方案。

典型输出：

• 技术方案。
• 架构说明。
• 模块拆解。
• 实现任务列表。
• 技术风险说明。

5.4 Engineer Agent

工程师 Agent 负责具体实现。

职责：

• 根据技术 Leader 的任务编写代码。
• 修改文件、配置、脚本。
• 输出实现说明。
• 记录变更内容。
• 遇到实现阻塞时反馈给技术 Leader。
• 根据测试反馈修复问题。

典型输出：

• 代码变更。
• 实现日志。
• 运行说明。
• 阻塞说明。

5.5 Tester Agent

测试 Agent 负责验证目标是否真的被实现。

职责：

• 根据验收标准制定测试方案。
• 运行单元测试、集成测试、端到端测试或手动验证步骤。
• 记录测试结果。
• 输出缺陷报告。
• 把结果反馈给产品经理 Agent。

典型输出：

• 测试计划。
• 测试用例。
• 测试结果。
• 缺陷报告。
• 回归测试结论。

5.6 Web Dashboard

Web Dashboard 是用户观察系统运行状态的入口。

职责：

• 显示所有 Agent 的在线状态和当前任务。
• 显示目标当前阶段和迭代轮次。
• 显示产品经理 Agent 的最新目标判断。
• 显示命令从产品经理到其他 Agent 的流动路线。
• 显示时间线和事件日志。
• 标记阻塞点和需要用户介入的节点。

6. 标准工作流

用户输入目标
 |
 v
产品经理 Agent 理解目标
 |
 v
产品经理 Agent 定义验收标准
 |
 v
技术 Leader Agent 设计技术方案
 |
 v
工程师 Agent 实现功能
 |
 v
测试 Agent 验证结果
 |
 v
产品经理 Agent 判断目标是否达成
 |
 +-- 已达成 -> 输出最终总结，任务完成
 |
 +-- 未达成 -> 生成下一轮跟进任务
                 |
                 v
               重新进入技术方案 / 实现 / 测试

关键点：

• 产品经理 Agent 是闭环判断者。
• 测试通过不一定代表目标达成，最终还要由产品经理 Agent 对照验收标准判断。
• 如果目标未达成，系统自动进入下一轮。
• 用户不需要每轮手动确认“是否继续”。

7. 命令流动路线

产品经理 Agent 每次下发指令，都应该形成一条可追踪的路线。

示例：

Command ID: cmd_001

产品经理 Agent
  |
  | 指令：补齐用户创建项目后的保存和展示流程
  v
技术 Leader Agent
  |
  | 拆解：后端保存接口、前端列表展示、测试验收点
  v
工程师 Agent
  |
  | 实现：修改接口、页面和状态管理
  v
测试 Agent
  |
  | 结果：项目可以保存，但刷新后列表为空
  v
产品经理 Agent
  |
  | 判断：目标未达成
  v
下一轮 Command: cmd_002

每条命令需要记录：

• 命令 ID。
• 所属目标 ID。
• 所属迭代轮次。
• 发起 Agent。
• 接收 Agent。
• 指令内容。
• 创建时间。
• 当前状态。
• 执行结果。
• 后续派生命令。

8. Web 页面需要展示什么

8.1 全局总览

展示：

• 当前目标。
• 目标状态：未开始、执行中、目标已达成、阻塞、失败。
• 当前迭代轮次。
• 产品经理 Agent 最新判断。
• 4 个 Agent 的当前状态。
• 未解决问题数量。
• 需要用户介入的节点。

8.2 Agent 状态面板

每个 Agent 展示：

• 角色。
• 在线状态。
• 当前任务。
• 当前任务开始时间。
• 最近心跳时间。
• 最近输出摘要。

Agent 状态建议：

• offline：未连接。
• idle：空闲。
• assigned：已分配任务。
• working：执行中。
• waiting_tool：等待工具结果。
• waiting_approval：等待用户授权。
• reporting：提交结果中。
• blocked：阻塞。

8.3 命令流动图

展示产品经理指令如何流向其他 Agent。

需要支持：

• 查看一条命令的完整流转。
• 查看当前命令卡在哪个 Agent。
• 查看某个 Agent 处理后的输出。
• 查看这条命令是否产生了下一轮命令。

8.4 时间线

展示事件发生顺序。

示例：

10:00 用户创建目标
10:01 产品经理 Agent 生成验收标准
10:05 技术 Leader Agent 生成技术方案
10:12 工程师 Agent 提交实现结果
10:16 测试 Agent 发现 2 个问题
10:18 产品经理 Agent 判断目标未达成
10:19 Orchestrator 创建下一轮任务

9. HTTP API 草案

9.1 任务 API

POST /tasks
GET /tasks
GET /tasks/{task_id}
POST /tasks/{task_id}/start
POST /tasks/{task_id}/pause
POST /tasks/{task_id}/resume

9.2 Agent API

POST /agents/register
GET /agents
GET /agents/status
GET /work/next?role={role}
POST /agent-runs/{run_id}/heartbeat
POST /agent-runs/{run_id}/result

9.3 消息与命令 API

POST /messages
GET /tasks/{task_id}/messages
POST /commands
GET /tasks/{task_id}/commands
GET /commands/{command_id}
GET /tasks/{task_id}/command-routes

9.4 工具调用 API

POST /tool-calls
GET /tool-calls/{tool_call_id}
POST /tool-calls/{tool_call_id}/approve
POST /tool-calls/{tool_call_id}/reject

9.5 Web 可视化 API

GET /dashboard/overview
GET /tasks/{task_id}/graph
GET /tasks/{task_id}/timeline
GET /events/stream

第一版可以先用定时刷新。等核心流程跑通后，再用 SSE 或 WebSocket 做实时推送。

10. 核心数据结构

10.1 Task

表示用户输入的目标。

字段：

• id
• title
• goal
• status
• current_iteration
• acceptance_criteria
• created_at
• updated_at

10.2 Agent

表示一个 AI Worker。

字段：

• id
• role
• name
• status
• last_heartbeat_at
• current_run_id

10.3 AgentRun

表示某个 Agent 的一次执行。

字段：

• id
• task_id
• agent_id
• role
• input
• output
• status
• started_at
• finished_at

10.4 Command

表示产品经理或 Orchestrator 下发的一条指令。

字段：

• id
• task_id
• iteration
• from_agent
• to_agent
• content
• status
• parent_command_id
• result
• created_at
• updated_at

10.5 Event

表示系统中发生的一件事，用于 Web 时间线。

字段：

• id
• task_id
• type
• actor
• summary
• payload
• created_at

10.6 ToolCall

表示 Agent 请求调用工具。

字段：

• id
• task_id
• agent_run_id
• tool_name
• input
• status
• requires_approval
• output
• created_at
• finished_at

11. 服务模块拆分

第一版后端可以拆成：

• TaskService：管理目标和任务状态。
• AgentService：管理 Agent 注册、心跳和在线状态。
• WorkflowService：决定下一步分配给谁。
• GoalReviewService：判断目标是否达成。
• CommandRouteService：记录命令流动路线。
• MessageService：记录 Agent 消息。
• EventService：记录事件并服务 Web 时间线。
• DashboardService：聚合 Web 页面需要的数据。
• ToolService：管理工具调用和授权。
• StorageService：负责持久化。

12. 一步一步实现路线

Step 1：创建基础目录和文档

目标：

• 建立 EchoAgent 项目骨架。
• 固化多 AI 协同的核心设计。

需要实现：

• README.md
• server/
• web/
• agents/
• runs/
• config/

交付物：

• 清晰的项目结构。
• 当前这份框架文档。

Step 2：实现 HTTP Orchestrator 基础服务

目标：

• 先让本地 HTTP 服务跑起来。

需要实现：

• 服务启动入口。
• 健康检查接口：GET /health
• 基础配置读取。
• 简单内存存储或文件存储。

交付物：

• 可以启动的 HTTP 服务。
• 浏览器或 curl 可以访问健康检查。

Step 3：实现任务创建和任务状态

目标：

• 用户可以创建一个目标。
• Orchestrator 可以记录目标状态。

需要实现：

• POST /tasks
• GET /tasks
• GET /tasks/{task_id}
• Task 数据结构。

交付物：

• 能创建任务。
• 能查询任务。
• 任务有明确状态。

Step 4：实现 Agent 注册和心跳

目标：

• 多个 cmd 中的 Agent Worker 可以连接 Orchestrator。

需要实现：

• POST /agents/register
• GET /agents/status
• POST /agent-runs/{run_id}/heartbeat
• Agent 数据结构。

交付物：

• Web 或 API 能看到 4 个 Agent 是否在线。
• Agent 有角色和状态。

Step 5：实现任务分配机制

目标：

• Agent Worker 可以向 Orchestrator 领取自己的任务。

需要实现：

• GET /work/next?role={role}
• POST /agent-runs/{run_id}/result
• AgentRun 数据结构。
• 简单的固定顺序工作流。

第一版顺序：

product_manager -> tech_leader -> engineer -> tester -> product_manager_goal_review

交付物：

• Agent 能领取任务。
• Agent 能提交结果。
• Orchestrator 能进入下一阶段。

Step 6：实现产品经理目标判断

目标：

• 产品经理 Agent 能判断目标是否达成。
• 未达成时自动创建下一轮任务。

需要实现：

• 验收标准字段。
• GoalReviewService
• 目标状态更新。
• 自动下一轮逻辑。

交付物：

• 测试结果回到产品经理 Agent。
• 产品经理输出“已达成”或“未达成”。
• 未达成时系统自动进入下一轮。

Step 7：实现命令和消息流转记录

目标：

• 产品经理下发的每条指令都可以被追踪。

需要实现：

• Command 数据结构。
• POST /commands
• GET /tasks/{task_id}/commands
• GET /tasks/{task_id}/command-routes
• CommandRouteService
• MessageService

交付物：

• 能看到一条命令从谁发给谁。
• 能看到命令处理结果。
• 能看到派生出的下一轮命令。

Step 8：实现 Web Dashboard 第一版

目标：

• 用户有一个页面可以总览多 AI 工作状态。

需要实现：

• 全局总览页。
• Agent 状态面板。
• 任务详情页。
• 时间线。
• 命令流动路线展示。

第一版可以先用定时刷新，不必实时推送。

交付物：

• Web 页面能看到 4 个 Agent 状态。
• 能看到当前任务阶段。
• 能看到命令路线。
• 能看到目标是否达成。

Step 9：实现工具调用记录和授权

目标：

• Agent 可以请求调用本地工具。
• 高风险工具调用需要用户确认。

需要实现：

• ToolCall 数据结构。
• POST /tool-calls
• POST /tool-calls/{tool_call_id}/approve
• POST /tool-calls/{tool_call_id}/reject
• 工具调用日志。

第一版工具：

• 文件读取。
• 文件写入。
• Shell 命令。
• 测试命令。
• Git 状态查看。

交付物：

• 工具调用可记录。
• 高风险调用可拦截。
• Web 页面能看到工具调用状态。

Step 10：实现持久化和运行记录

目标：

• 系统重启后还能恢复任务状态。
• 每次运行都有记录。

需要实现：

• 文件存储或数据库存储。
• runs/{task_id}/ 运行目录。
• 任务快照。
• 时间线文件。
• 命令路线文件。

交付物：

• 任务不会因为服务重启丢失。
• 用户可以复盘历史运行过程。

Step 11：实现实时事件推送

目标：

• Web 页面实时更新 Agent 状态和任务进度。

需要实现：

• GET /events/stream
• SSE 或 WebSocket。
• EventService 推送状态变化。

交付物：

• Agent 状态变化实时显示。
• 命令流动路线实时更新。

Step 12：完善安全边界和失败处理

目标：

• 系统能长期运行，并处理失败、阻塞和风险操作。

需要实现：

• 最大迭代次数。
• 失败重试。
• 阻塞状态。
• 用户介入节点。
• 高风险命令审批。
• 任务暂停和恢复。

交付物：

• 系统不会无限失控循环。
• 用户可以看到为什么阻塞。
• 用户可以恢复或停止任务。

13. MVP 最小闭环

第一版最小可用闭环应该做到：

1. 启动 HTTP Orchestrator
2. 打开 Web Dashboard
3. 用户创建一个目标
4. 产品经理 Agent 生成验收标准
5. 技术 Leader Agent 生成技术方案
6. 工程师 Agent 输出实现结果
7. 测试 Agent 输出测试结果
8. 产品经理 Agent 判断目标是否达成
9. 未达成则自动创建下一轮任务
10. Web 页面显示 Agent 状态、时间线和命令流动路线

MVP 暂时不需要：

• 复杂权限系统。
• 远程分布式 Agent。
• 向量数据库。
• 多模型动态路由。
• 完整 CI/CD。
• 完整 IDE 插件。

14. 当前已实现的完整版骨架

当前目录已经实现了一个可运行的 EchoAgent 多 AI 协同骨架：

• 本地 HTTP Orchestrator。
• JSON 文件持久化。
• 任务创建、启动、暂停、恢复。
• Agent 注册、心跳、任务领取、结果提交。
• 产品经理先提出澄清问题，等待用户回答后才进入 PRD 输出。
• PRD Markdown 自动写入 workspace/{task_id}/product.md。
• 技术 Leader 基于 PRD 输出技术架构，并写入 workspace/{task_id}/architecture.md。
• 点击 Web 里的 Markdown 制品可以打开浏览器渲染页面：/artifacts/{artifact_id}/view。
• 技术 Leader 的架构方案会回到产品经理复核，通过后才进入工程实现。
• 产品经理目标复核和自动下一轮。
• 命令路线、消息、事件时间线。
• 工具调用记录和审批接口。
• Codex 风格 Web 页面：左侧项目列表，右侧工作台，下方对话框。
• 点击任意 Agent 卡片可打开弹窗，直接查询、纠正或追加约束。
• Agent 工作状态区升级为可编辑工作流画布：可以添加、编辑、删除角色，也可以给角色连线表达协作关系。
• 保存或运行画布后，当前产品会使用这份工作流配置启动。
• 当产品经理或其他 AI 需要用户确认时，对应 Agent 节点会高亮提示，点击节点即可交互回答。
• 事件时间线改为多人协同 git 图样式，点击行展开详情。
• 最近 Agent 输出默认只显示 3 条，其余收缩。
• SSE 事件流。
• 内置模拟 Agent，可以自动跑通闭环。
• 外部 Worker 客户端，可以在不同 cmd 中接入不同角色。

14.0 产品化启动入口

现在推荐新用户直接使用一键启动脚本：

cd C:\Users\user\Desktop\flechazo\02_project\00_flechazo\flechazo\EchoAgent
.\run.ps1

Windows 用户也可以直接双击：

run.cmd

run.ps1 会读取：

EchoAgent/data/runtime-config.json

如果这个文件不存在，脚本会自动创建默认配置：

• 启动 Orchestrator 服务。
• 默认启动内置产品经理、技术 Leader、测试 Agent。
• 如果检测到 codex 或 codex.ps1，默认启动一个真实 Codex 工程师 Worker。
• 如果没有检测到 Codex，默认连工程师也使用内置模拟 Agent，保证新用户第一次可以先跑通产品流程。
• 自动打开 http://127.0.0.1:8765。

不同用户的 Codex 启动方式不一样，所以不要把 codex.ps1 路径写死到代码里。打开 Web 页面后，点击左侧 本地运行设置，可以配置：

• 服务 Host / Port。
• Python 命令。
• Codex 启动器路径，可以是 codex、codex.cmd、codex.ps1 或完整路径。
• Workspace 输出目录。
• Codex Model 和 Timeout。
• 每个角色是否使用内置模拟 Agent。
• 每个角色是否启动外部 Worker，以及 Worker 是人工输入还是 Codex。

保存配置后，再运行：

.\run.ps1

就会按当前配置启动服务和 Worker。旧的启动方式仍然可用，但产品入口以后以 run.ps1 和 Web 里的 本地运行设置 为准。

14.1 启动演示模式

演示模式会启动 Orchestrator 和 4 个内置模拟 Agent。

cd C:\Users\user\Desktop\flechazo\02_project\00_flechazo\flechazo\EchoAgent
.\start.ps1 -AutoAgents

然后打开：

http://127.0.0.1:8765

在 Web 页面点击左侧 + 创建产品。新产品启动后不会立刻实现，产品经理 Agent 会先提出一组澄清问题。你在底部对话框选择 产品经理 并回答后，系统会进入 PRD、技术方案、产品复核、工程实现、测试、目标复核闭环。

14.2 启动纯 Orchestrator

如果你希望用不同 cmd 中的外部 Worker 接入，不启动内置模拟 Agent：

.\start.ps1

然后分别开 4 个 cmd 或 PowerShell：

.\worker.ps1 -Role product_manager
.\worker.ps1 -Role tech_leader
.\worker.ps1 -Role engineer
.\worker.ps1 -Role tester

每个 Worker 会注册到 Orchestrator，领取对应角色任务。当前 Worker 客户端是人工输入版：它会把 Orchestrator 指令打印出来，你输入该 Agent 的输出后用单独一行 END 提交。后续可以把这里替换成真实 Codex 调用。

14.3 接入真实 Codex 工程师 Agent

如果要让 AI 真正写文件，第一步建议先只把 工程师 Agent 换成真实 Codex，其他角色仍然用内置模拟 Agent。这样流程仍然能自动推进，同时工程实现阶段会由真实 Codex 在本地写代码。

先启动 Orchestrator，并只启用产品经理、技术 Leader 和测试模拟 Agent：

.\start.ps1 -AutoAgents -AutoAgentRoles "product_manager,tech_leader,tester"

再开一个新的 PowerShell，启动真实 Codex 工程师：

.\real-engineer.ps1

这个脚本默认通过下面的启动器调用 Codex：

优先读取 data/runtime-config.json 中的 codex_launcher；
如果没有配置，会尝试从 PATH 中查找 codex。

真实工程师 Agent 会：

• 注册为 engineer 角色。
• 从 Orchestrator 领取工程实现任务。
• 调用 codex exec 非交互模式。
• 在 EchoAgent/workspace/ 下创建或修改真实文件。
• 把 Codex 的最终总结、退出码、输出文件列表提交回 Orchestrator。

真实文件输出位置：

EchoAgent/workspace/

Codex 最后一条总结会保存到类似：

EchoAgent/workspace/codex-last-message-run_xxx.md

如果你希望 Codex 在别的项目目录里写文件，可以指定 workspace：

.\real-engineer.ps1 -Workspace "C:\Users\user\Desktop\my-project"

这种情况下，真实工程师 Agent 会在你指定的项目目录里实现文件变更。

如果你的 Codex 启动脚本换了路径，可以显式指定：

.\real-engineer.ps1 -CodexLauncher "C:\path\to\codex.ps1"

更推荐的方式是在 Web 页面左侧点击 本地运行设置 后保存 Codex 启动器路径，然后用：

.\run.ps1

14.4 常用 API

GET  /health
POST /tasks
GET  /tasks
GET  /tasks/{task_id}
POST /tasks/{task_id}/start
POST /agents/register
GET  /agents/status
GET  /work/next?role={role}
POST /agent-runs/{run_id}/result
GET  /dashboard/overview
GET  /tasks/{task_id}/command-routes
GET  /tasks/{task_id}/timeline
GET  /events/stream
POST /tasks/{task_id}/interventions

数据会保存到：

EchoAgent/data/state.json

14.5 如何在 Web 端和 4 个 AI 交互

Web 页面现在支持三类交互：

1. 查询状态。

   • 左侧查看产品列表和当前产品状态。
   • 右侧 Agent 工作流画布 查看每个 AI 在线、空闲、执行中、当前阶段和待处理命令。
   • 画布支持添加、编辑、删除角色，并通过连线表达角色关系。
   • 最近 Agent 输出 默认显示最近 3 条，点击展开可以看更多。
   • 事件时间线 用多人协同图展示命令和事件流，点击一行展开详情。
   • 制品 区域显示 PRD 和技术架构 Markdown。点击制品会打开浏览器渲染版，也会在侧栏保留源码预览。

2. 控制任务。

   • 点击 暂停 可以暂停当前任务。
   • 点击 恢复 可以恢复任务。
   • 暂停后可以先发纠正指令，再恢复任务。

3. 和任意 Agent 交互。

   你有两种入口：

   • 底部对话框选择目标 Agent 后发送消息。
   • 点击 Agent 工作流画布 中的任意角色节点，在弹窗里查询状态、纠正方向、追加约束或要求复核。
   • 产品经理 Agent：纠正目标、追加验收标准、要求重新判断目标是否达成。
   • 技术 Leader Agent：调整技术路线、要求重新拆分任务。
   • 工程师 Agent：纠正实现方向、要求修复指定问题。
   • 测试 Agent：追加测试点、要求重新验证。

   产品澄清阶段比较特殊：当任务状态是 waiting_user 且当前阶段是 product_clarification 时，你给产品经理发送的第一条回答会被视为澄清回答。系统随后会让产品经理输出 PRD，并继续调度技术 Leader。

发送给 Agent 的消息会变成一条来自 user 的命令，并记录到时间线中。这样人工介入不是口头修改，而是可追踪的协作事件。

14.6 AI 输出在哪里

EchoAgent 现在区分三类输出：

EchoAgent/workspace/{task_id}/product.md
EchoAgent/workspace/{task_id}/architecture.md
EchoAgent/workspace/

• 产品经理的 PRD 输出在 workspace/{task_id}/product.md。
• 技术 Leader 的技术架构输出在 workspace/{task_id}/architecture.md。
• 工程师 Agent 真正创建或修改的代码在 workspace/。
• 如果你用 .\real-engineer.ps1 -Workspace "C:\path\to\project" 指定了工作目录，工程师代码会输出到你指定的目录。
• Codex 最后一条总结会写到 workspace/codex-last-message-run_xxx.md。

Web 页面右侧 制品 区会显示 PRD 和架构文档。点击制品会打开 /artifacts/{artifact_id}/view，浏览器会渲染 Markdown 供你阅读；工程代码需要到 workspace/ 查看。

14.7 新流程 API

新增或重点使用的接口：

POST /tasks/{task_id}/chat
GET  /tasks/{task_id}/artifacts
GET  /artifacts/{artifact_id}
GET  /artifacts/{artifact_id}/content
GET  /artifacts/{artifact_id}/view
GET  /tasks/{task_id}/workflow
POST /tasks/{task_id}/workflow
POST /tasks/{task_id}/run-workflow

典型状态流：

created
 -> running / product_clarification
 -> waiting_user / product_clarification
 -> running / product_planning
 -> running / tech_planning
 -> running / architecture_review
 -> running / implementation
 -> running / testing
 -> running / goal_review
 -> done 或进入下一轮

15. 建议目录结构

EchoAgent/
  README.md
  start.ps1
  worker.ps1

  echoagent/
    server.py
    services.py
    storage.py
    simulator.py
    worker.py

  server/
    app.md
    api.md
    services.md
    storage.md

  web/
    dashboard.md
    agent-status.md
    command-routes.md
    timeline.md

  agents/
    product_manager.md
    tech_leader.md
    engineer.md
    tester.md

  workflows/
    product_to_mvp.md
    goal_review_loop.md

  tools/
    filesystem.md
    shell.md
    git.md
    tests.md

  config/
    agents.yaml
    tools.yaml
    workflow.yaml

  runs/
    example-task/
      context.md
      product.md
      architecture.md
      implementation.md
      test-report.md
      goal-review.md
      command-routes.md
      timeline.md
      iteration-log.md

16. 当前最终理解

EchoAgent 要做的是一个“多 AI 协同工作系统”。

用户输入目标后，产品经理 Agent 持续负责目标闭环；技术 Leader Agent 负责技术路线；工程师 Agent 负责实现；测试 Agent 负责验证；Orchestrator 负责调度和状态管理；Web Dashboard 负责展示全局状态、Agent 工作状态、命令流动路线和迭代过程。

最终效果应该是：

用户不需要一直追问系统下一步该做什么。只要目标未达成，EchoAgent 就会继续跟进、分配、执行、测试和复核，并把整个过程清晰展示在 Web 页面上。