一句话：阿里云那篇Agent四层架构，我拆了三遍。花80%篇幅解决的是100人团队的协作问题。一人公司只需要那20%——3个文件，跑通一个项目链条。

---

一、起因：一个独立开发朋友问我"要不要搭Agent架构"

事情是这样的。

上个月一个做独立开发的朋友甩给我一篇文章，问：“你看阿里云那篇Agent架构了吗？业务专家Agent、上下文编排层、工具执行层、反馈闭环——我觉得我也得搭一个。”

我说别。你那项目就你一个人加一两个工具。他那套是给100个人的团队设计的。你抄了，只会让自己干更多活。

然后我花了两天把那篇架构文拆了三遍。拆完发现一件事：大厂花80%精力解决的问题，你根本不需要解决。你需要的那20%，3个文件就够了。

---

二、先把两套问题分清楚

我把大厂的Agent四层架构和一人公司的真实需求做了个对比，看完你就知道差距在哪：

架构层	大厂在解决什么	一人公司的真相	冗余度
上下文输入层	100人怎么读到同一份需求文档	需求在你脑子里，写给AI看就行	80%冗余
业务专家编排层	不同角色（产品/开发/测试）怎么接力	你手动切换角色就是最好的编排	90%冗余
工具执行层	多个内部平台怎么打通	你一个人就是工具链调度器	85%冗余
反馈学习层	跨团队的知识怎么回流	CHANGELOG+复盘就够了	70%冗余

核心差异：

大厂问题：协作效率——100个人怎么不出错地干同一件事
一人公司问题：注意力分配——你一个人怎么把有限精力放在最关键的地方

这是两个完全不同的问题。大厂的每一层都在解决"人一多就乱"的问题。你一个人，没有这个问题。

但你也有你没有的问题——你一个人要干5个角色的活，怎么保证不漏、不错、不跑偏？

那20%你需要的东西，就是为了解决这个。

---

三、我需要的3个文件（带模板）

文件1：AGENTS.md — 给AI定边界和标准（可复制模板）

大厂的上下文输入层，本质上是让100个人知道"现在在干什么"。你的AGENTS.md也是干这个——但你是写给AI看的。

我现在的AGENTS.md长这样：

# 项目级 AI 协作规范

## 项目背景
- 项目名称：{项目名}
- 技术栈：{Python 3.11 + FastAPI / React 18 + TypeScript / PostgreSQL 15}
- 代码风格：{Black / Prettier / ESLint}
- 提交规范：Conventional Commits

## 当前任务
详见 ROADMAP.md

## 边界约束（最重要）
- 在开始任何新任务前，先用一句话告诉我"你理解的这个任务是什么"
- 我确认了再开始执行
- 以下情况必须停下来问我：
  - 需求文档里没有覆盖到的场景
  - 需要我提供API密钥或数据库密码
  - 发现前置依赖不满足

## Agent角色定义（我一人多角色）
- 产品经理Agent：输出PRD、拆需求、定优先级
- 架构师Agent：输出技术方案、模块拆分、接口设计
- 开发Agent：代码生成、单元测试
- QA Agent：测试用例、回归测试、日志分析

踩过一个坑：项目跑了2周，Codex写了很多代码，但每次提交都在偏离方向。我发现原因——我没在AGENTS.md写清楚"这个项目的边界是什么"。Codex以为我在做A，其实我在做B。它跑得越快，错得越远。

后来加了一行"在开始任何新任务前，先用一句话告诉我你理解的任务是什么"——就这一行，后面再没出过方向偏差。

文件2：质量门检查清单

质量门这个概念，是我从大厂架构里唯一一个全盘吸收的。

大厂最关键的设计不是自动化，是质量门——每过一个节点，必须人停一步确认，才能进下一阶段。

一人公司的质量门链条：

需求阶段
  ├── 我确认：需求本身是对的 → 进入方案阶段
  │
方案阶段
  ├── 我确认：方案覆盖了所有需求 → 进入开发阶段
  │
开发阶段
  ├── 我确认：代码实现了方案，通过了自测 → 进入测试阶段
  │
测试阶段
  ├── 我确认：测试用例覆盖了核心路径 → 进入验收阶段
  │
验收阶段
  ├── 我确认：可以上线了

这是我写的质量门自检脚本（Python），每次切换阶段前跑一遍：

# quality_gate.py — 一人公司质量门检查
# 在关键节点前运行，确认可以进入下一阶段

GATE_CHECKLIST = {
    "需求→方案": [
        "需求文档是否覆盖了所有用户场景？",
        "有没有遗漏的异常流程？",
        "这个需求真的值得做吗？（不是所有需求都值得做）",
    ],
    "方案→开发": [
        "技术方案有没有评审过？",
        "数据库变更有没有回滚脚本？",
        "API接口签名和现有的是否兼容？",
    ],
    "开发→测试": [
        "所有单元测试通过了？",
        "有没有新增的配置项需要记录？",
        "代码有没有遗留的TODO或FIXME？",
    ],
    "测试→验收": [
        "核心路径有没有覆盖？",
        "有没有测过异常场景？",
        "性能有没有明显退化？",
    ],
}

def check_gate(stage):
    print(f"\n=== 质量门：{stage} ===")
    for item in GATE_CHECKLIST.get(stage, []):
        answer = input(f"  {item} (y/n): ")
        if answer.lower() != "y":
            print(f"  ⛔ 未通过：{item}")
            return False
    print("  ✅ 通过，可以进入下一阶段")
    return True

# 使用
# check_gate("方案→开发")

这里有一个教训：有段时间我觉得这套流程太慢，让AI自己把需求→方案→代码全部串起来跑。第二天早上，它帮我写完了一整个模块的代码。但我仔细一看——需求本身就是错的。需求错了，方案跟着错。方案错了，代码全白写。自动化链条越长，错得越离谱。

自动化跑得快，前提是对齐了。对齐的前提，是人停一步想清楚。

文件3：_CHANGELOG.md — 记判断的升级（记录模板）

大厂的反馈学习层，本质上是把踩过的坑沉淀下来，下次别踩同一个。

你一个人，没有PM帮你复盘，只能自己记。我的记法不是写流水账，是写判断的升级：

# CHANGELOG

## 2026-06-24
### 这周让我对AI协作的理解改变了什么
1. 质量门不能跳过——跑得快不如方向对
2. AGENTS.md最重要的不是"怎么写"，是"边界写清楚"
3. 让AI先陈述理解再执行，比直接给指令安全

### 踩坑记录
- 项目：{项目名}
- 问题：需求没对齐就让AI开跑，写了3天全白费
- 根因：省略了"你理解的任务是什么"这个确认步骤
- 修复：在AGENTS.md加上边界约束段落

### 下阶段要试的
- 给AI分配独立的线程，一个线程只做一件事

格式就三块：判断的升级 + 踩坑记录（含根因） + 下阶段要试的。一次写完不超过5分钟。

这个习惯我保持了快两个月。回头看第一周的记录，跟现在的判断完全是两个层次。不是说AI进步了，是我对"AI能做什么、不能做什么"的理解变了。

---

四、三个文件的协作关系

这三个文件不是一个替代另一个，它们组成一条闭环：

AGENTS.md — 告诉AI你是谁、边界在哪（写在前面）
     ↓
质量门 — 在每个关键节点停一步检查（跑在中间）
     ↓
CHANGELOG — 把踩坑沉淀下来，下次不犯（写在后面）
     ↑
（循环：CHANGELOG里的经验会反过来更新AGENTS.md）

大厂那套四层架构看完后，你需要的是这三件事：定标准、设门禁、记踩坑。三个文件，不需要花三个月去搭复杂的编排引擎。

---

五、一个直接的建议：今天就能做的事

1. 在你的项目根目录创建一个 AGENTS.md，把上面的模板复制进去，改掉你的项目名
2. 把 quality_gate.py 保存下来，每次阶段切换前跑一遍
3. 创建一个 _CHANGELOG.md，每次项目做完或每周结束，写一段判断升级

先跑通一个项目看看效果。你不需要转型，你只需要加这三个文件。

---

六、结尾

那篇大厂Agent架构文还躺在我的浏览器标签页里。我把它当参考，不当圣经。

因为我知道：我的问题不是100个人怎么协作，是我一个人怎么把5个角色的活干完、干对、干爽。

这三个文件帮我做到了。

---

你也在用AI搭工作流吗？你抄过大厂的方案然后发现不适用的情况吗？评论区说说你的场景，我帮你看看哪个文件能先落地。