Trae (max_steps=200) vs Pi-EPEC 编排

1 · 背景与目标

2 · 实验环境与配置

2.1 模型 (两路径共用)

2.2 工具链对比

2.3 trae 配置 (max_steps: 50 → 200)

agents:
  trae_agent:
    model: glm-5.2
    max_steps: 200          # ← 从 50 调到 200
    tools: [bash, str_replace_based_edit_tool, sequentialthinking, task_done]

2.4 pi-epec 编排配置 (节选)

subagents:
  - { name: pi-explorer,  type: pi, model: sub2api-completions/glm-5.2, thinking: medium, tools: [read,grep,find,ls,bash] }
  - { name: pi-planner,   type: pi, model: sub2api-completions/glm-5.2, thinking: medium, tools: [read,grep,bash] }
  - { name: pi-executor,  type: pi, model: sub2api-completions/glm-5.2, thinking: medium, tools: [read,write,edit,bash] }
  - { name: pi-checker,   type: pi, model: sub2api-completions/glm-5.2, thinking: medium, tools: [read,grep,find,ls,bash] }
# 每个 subagent 加载 .agents/skills/ui/SKILL.md, 用 pi-epec 生成的 *.j2 prompt 模板

3 · 任务 Prompt

两路径接收同一任务核心 (step2_generate.md), pi 路径由 orchestrator 拆解到 4 个角色:

任务: 阅读 timesheet_system_platform_plan_v14.html, 做有界第一刀生成.
1. 读 AGENTS.md + ui skill 三维度, 确认设计风格/目录/模块拆分规则
2. 写 docs/design/module-split.md (模块清单: 职责+边界)
3. 建模块目录骨架 (src/views/timesheet/<module>/)
4. **生成工时填报样例页 index.vue** (组件选择决策 + design token)
5. 对照 conventions 文档一致性原则自查

trae: 5 项一次性塞给单体
pi:   explorer(读) → planner(拆任务+验证标准) → executor(生成+自验) → checker(独立复核)

4 · 路径 A: trae (200步) 执行记录

4.1 trajectory 实测

关键转变: 给足步数后 trae 在第 78 步主动 task_done, 补齐了样例页. 证明"50步漏交付"是步数预算不足, 不是模型能力问题.

4.2 但暴露新问题: design token 未落地

5 · 路径 B: pi-epec 编排执行记录

5.1 编排执行记录

5.2 checker 捕获的边界越权 (trae 无此环节)

关键: pi 主动建立了 design.scss (token 落地), 并由 checker 复核; trae 没建. 这是质量深度的核心差异.

6 · 渲染截图对比 (所有页面)

用独立 Vite 沙箱 + playwright headless 渲染两路径所有生成的页面 (viewport 1440×900 @2x). 注意: 所有截图都注入了 design token CSS 变量才正常显示 — trae 项目本身无 token 文件, 不补值则是无样式白板.

6.1 核心样例页对比 (工时填报)

路径 A · trae200 (timesheet)

209 行 · 表格 No Data (无数据) · 无标题 · 4 按钮 · Charge Code 搜索缺失

路径 B · pi-epec (timesheet)

342 行 · 标题“周工时填报” · Charge Code 远程搜索 · 有行数据 · 7 按钮

6.2 pi-epec 全部模块页面 (trae 只生成了 1 个页面, 无对应物)

pi 按模块拆分维度生成了 8 个业务模块页面; trae200 仅生成 1 个页面 (timesheet), 其余 7 个模块无对应产物. 下面是 pi 的其余 7 个模块页面 (均为占位骨架, 符合一期“骨架生成”定位, 每页有标题 + 模块职责说明 + design token 取值):

Charge Code 管理

受控核算对象生命周期

审查审批

备案/确认/异常审批三线

预算管控

额度/占用/预警

成本归集

小时成本率/费用归集

管理看板

经营驾驶舱

组织主体

集团/公司/成本中心

期间管理

周度周期/月度锁定/状态机

6.3 渲染证据 (playwright DOM 实测)

pi 不仅样例页更完整, 还多生成了 7 个模块页面骨架; trae 只交付了单个样例页. 且 trae 的 token 引用“悬空” (无落地文件).

6.4 pi 样例页 design token 落地 (design.scss, 44 行)

:root {
  --ts-color-canvas: #f7f3ed;      // 页面暖白背景
  --ts-color-surface: #fffdfa;     // 卡片表面
  --ts-color-primary: #a77b4c;     // 品牌强调(焦糖)
  --ts-color-data-blue: #2869e7;   // 数据/链接
  --ts-color-ink: #2a2520;         // 正文墨色
  --ts-color-danger: #c0392b;      // 风险
  --ts-spacing-md: 16px;           // 8px 网格
  --ts-radius-card: 8px;
  --ts-elevation-card: 0 1px 3px rgba(42,37,32,.06);
}

trae 无此文件. 样例页的 var(--ts-color-bg) 等引用全部未定义.

7 · 对比分析

7.1 交付与质量

7.2 执行效率

8 · 结论

8.2 三点关键发现

1. 步数预算是硬约束: trae 50步漏交付, 200步能补齐. 单体 agent 的完成度强依赖 max_steps 配置.
2. 单体无检查 = 隐患自留: trae 引用未定义的 token 却自报 success=True, 这种"断裂"单体无法发现; pi 的 checker 是捕获它的唯一手段.
3. 编排的价值是质量下限: pi 多花的设计.scss 落地 + checker 闭环, 把"看起来完成但有隐患"变成"FAIL 可返工". 这是单体 agent 给不了的.

8.3 适用场景

agent-stack-kit · trae200 vs pi-epec 对比 + 渲染验证 · 2026-06-26 · 模型 glm-5.2