建立 Agent 入职包
整理项目背景、目录说明、架构图、复用原则、禁区、常用命令和测试方式。
Appendix
附录把会议中的术语、指标、工具和下一步动作压缩成可复制的工作表,方便团队直接拿去改自己的流程。
Glossary
会议里的关键词很多,这里给出公开版解释。
| 术语 | 解释 |
|---|---|
| Harness Engineering | 围绕 Agent 自动化开发、测试、验收、上线和反馈回收建立的一套工程组织方式。 |
| 副驾模式 | 人盯着模型写代码,主要关注局部补全和修改。 |
| 管理者模式 | 人定义目标、上下文、边界、验收和沉淀机制,把 Agent 当可管理成员。 |
| Meta Spec | 跨项目复用的通用规范底座,包含安全、性能、资源、测试、体验等维度。 |
| Worktree | Git 的多工作树机制,可让多个分支在不同目录并行开发。 |
| 认知债务 | 术语、边界、变量、业务对象表达不清造成的长期理解成本。 |
| 资源感知 | 对端口、CPU、GPU、外部服务、线上线下差异等工程资源进行显式记录和管理。 |
Actions
从明天就可以开始做的事情。
整理项目背景、目录说明、架构图、复用原则、禁区、常用命令和测试方式。
所有 Agent 任务进入看板,卡片写清目标、范围、验收和资源要求。
列出适用条件、命名规则、端口分配、合并流程和废弃回收方式。
每次 Review 把重复错误沉淀成检查点、Skill、模板或自动测试。
用 Markdown 记录项目端口、CPU/GPU、服务依赖、账号和线上线下差异。
每 2-3 个月同步模型能力变化,更新默认模型、工具和工作流判断。
Metrics
指标不是 KPI,而是判断工程系统是否健康的仪表盘。
| 指标 | 建议观察 | 解释 |
|---|---|---|
| 并发 Agent 数 | 1 → 3 → 10 逐级提升 | 每一级都应能稳定验收,再提高并发。 |
| Deletions / Additions | 12%-15% 较健康,超过 30% 警惕 | 过高可能代表不必要重构或 Agent 失控。 |
| Spec 变化率 | 新增项尽量不超过 15% | 说明前期 Spec 覆盖了主要方向,同时保留迭代空间。 |
| 重复 Review 问题数 | 应逐轮下降 | 不下降说明经验没有变成自动约束。 |
| PR 可合并率 | 越高越好 | 衡量任务边界、测试和 Review 流程是否清晰。 |
Sources
公开资料入口。