别让所有 Agent 都来找你：为什么每个项目需要一个 AI Lead

上午还在排查 A 项目的 CI，午饭前被问 B 项目能不能发布，下午又收到 C 项目的 PR review。

每次切换项目，你都要重新加载一遍上下文：上次做到哪里？哪些坑已经踩过？哪些动作 AI 可以自己做？哪些必须由我审批？

我同时使用 Claude Code、Codex 等 AI CLI 推进多个项目后，越来越确信：

Agent 应用真正难的，不是单次任务能不能完成，而是多个项目、多个 Agent 和多个风险动作能不能被长期运营。

如果所有 Agent 遇到问题都直接来找你，老板很快就会被小决策淹没。更合理的组织关系应该是：

Boss
  └── Project Lead
        ├── Implementer
        ├── Tester
        ├── Reviewer
        └── Specialist

这篇文章想讨论的，正是我在开发 AI Company OS（AICO） 时形成的一个判断：每个项目都需要一个 AI Lead。

它不是一个更强的模型，也不是给 Agent 换个管理学名字，而是一组明确的职责、上下文和权限边界。

从 Agent Demo 到 Agent Operations

过去谈 Agent，大家通常先问：

• 能不能自动写代码？
• 能不能规划任务和调用工具？
• 能不能让多个 Agent 协作？

这些属于 Agent construction：怎么构建一个能完成任务的 Agent。

但当 Agent 开始长期参与真实项目，问题会变成：

• 不同项目的上下文会不会串线？
• 谁负责拆任务，谁负责验收？
• 危险动作由谁审批？
• 进程退出后，任务能不能恢复？
• 昨晚做了什么，今天能不能用一分钟说清楚？

我把后一层称为 Agent operations。

层次	核心问题	判断标准
Agent construction	怎么接模型、工具和工作流	能不能完成一次任务
Agent operations	怎么管理职责、权限、状态和交接	能不能长期、放心地托付

AutoGen、CrewAI、LangGraph 等框架已经分别覆盖了多 Agent 对话、角色与流程、持久化执行等能力。AICO 不打算替代它们。它选择的是一个更具体的切口：把开发者电脑上已有的 AI CLI，组织成一个可以通过 IM 远程管理的项目办公室。

AI Lead 不是“万能 Agent”

我说的 Lead，首先是一种项目职责：

• 维护项目当前目标和上下文；
• 把任务分给合适的角色；
• 汇总证据，减少老板重新进入现场的成本；
• 在授权范围内做有边界的判断；
• 遇到不可逆、破坏性、公开发布、凭据或支付等动作时升级给老板。

因此，Lead 可以组织工作，但不能绕过权限。

它的价值也不在于“替老板做所有决定”，而在于过滤小决策，把真正需要人判断的问题连同证据、风险和备选方案一起递上来。

为什么需要 Appointment 这一层

AICO 没有把 Role 和 Agent 混为一谈：

• Agent 是执行实体，例如 Claude Code、Codex；
• Role 是职责，例如 implementer、tester、reviewer；
• Project 是上下文边界；
• Appointment 表示某个 Agent 在某个 Project 中担任某个 Role。

Agent 1 --- n Appointment n --- 1 Project
                    |
                   Role

为什么不直接把 Role 挂在 Agent 上？

因为同一个 Agent 可以在项目 A 中担任 Lead，在项目 B 中担任 Reviewer。它在两个项目里的工作目录、会话、提示词、权限和历史任务都应该彼此隔离。

Appointment 正是这层隔离：它把“谁”“在哪个项目”“以什么职责”“拥有什么权限”绑定在一起。

这也意味着 Lead 不是一个写死的特殊 Agent，而是当前项目的默认 Appointment。更换 Lead 只需要调整任命关系，任务、审批和审计机制都不必另起一套。

一个 Lead 要解决的三个工程问题

1. 上下文：知道项目现在在哪里

多项目并行时，最危险的不是 Agent 忘记一句提示词，而是把 A 项目的经验带进 B 项目。

AICO 通过 Project 和 Appointment 隔离工作目录、Provider session、项目说明、角色提示词和审计轨迹，并把可复用信息分成两类：

• Memory：项目阶段、决策结论、老板偏好等事实；
• Experience：这个仓库先跑哪个测试、Review 时重点看什么等经过实践形成的经验。

事实更依赖当前查询，经验更依赖角色和场景，所以二者采用不同的召回方式。被注入任务的 Experience 会记录 ID，便于后续根据结果判断它究竟有没有帮助。

这样 Role 才不只是“岗位说明书”，而能逐渐变成项目里的熟手。

2. 协作：能委托，但不能越权

一条项目消息进入 AICO 后，大致经过：

IM message
  -> MessageRouter
  -> Task(project / role / session / memory metadata)
  -> RiskAssessor / ApprovalPolicy / capability gate
  -> AI Adapter
  -> TaskSnapshot + AuditEvent

如果 Lead 输出：

@reviewer: inspect this implementation for release risks

系统会创建一个 Reviewer 子任务，并保留父子任务关系。Reviewer 能看到必要的父任务上下文，但真正的委托会单独放在 Current task 中。

这里有个容易被忽略的细节：上下文和指令必须分离。

父任务可能提到 git push，但 Reviewer 当前收到的指令只是只读审查。风险判断如果扫描整段上下文，就会把“看到危险动作”误判成“被要求执行危险动作”。AICO 因此只根据当前任务判断行动风险。

权限控制也不依赖 Agent 自觉，而是经过三道门：

1. RiskLevel 区分只读、写文件、执行命令和破坏性动作；
2. Adapter capability gate 拒绝角色不支持的行为；
3. 非只读任务进入 ApprovalPolicy，由有权限的人批准或拒绝。

这不是企业级 RBAC，也不是安全沙箱，但在个人开发者、本机 CLI 和 IM-first 的范围内，它建立了一条清楚的底线：Agent 不能因为提示词写得自信就获得权限。

3. 交接：老板回来时，不必重新考古

假设下午有人突然问：

昨晚 Release 到哪了？今天还能不能发？

没有 Lead 时，你通常要打开终端、寻找任务、翻 Agent 输出、查测试结果，再自己组织结论。

AICO 希望把这个过程缩短为：

/project aico
/morning
/task <id>
/view

其中 /task 面向工程师展示任务 Trace，/morning 汇总最近进展，/view 则生成只读的 Boss Brief、Timeline、Trace 和 Memory 摘要。

/view 并不是一个需要从手机访问 Mac localhost 的 Web 控制台。AICO 会生成自包含 HTML，通过 Telegram 直接发送；所有写操作仍然回到 IM 命令，并继续经过审批和审计。

这套设计优化的不是“少敲几条命令”，而是减少重新进入项目现场的时间。

AICO 和现有框架是什么关系

框架或系统	更擅长的层次	与 AICO 的关系
LangGraph / LangSmith	Agent runtime、持久化工作流与部署	可借鉴或作为未来接入层
CrewAI	Crews、Flows、Agents 和 Tasks	可作为 Workflow backend
AutoGen	多 Agent 对话和事件驱动协作	可作为多 Agent backend
AICO	本机 AI CLI 的 IM-first operating layer	管理项目、职责、审批、审计、记忆和交接

AICO 要回答的不是“哪个 Agent 框架更强”，而是：

我已经有 Claude Code、Codex 等工具，怎样把它们组织成一个可以远程指挥、可审批、可追溯、可接手的项目团队？

当前边界

为了避免把 Demo 写成已经成熟的平台，当前边界也需要说清楚：

• 稳定的 IM 入口是 Telegram；飞书仍待生产验证；
• /overnight 第一阶段主要派给当前 Lead，并不是完整的多阶段自动调度器；
• AICO 是本机 CLI 的控制层，不是独立安全沙箱；
• Lead 可以做有边界的判断和只读协调，高风险动作仍需审批；
• Experience 已支持按 Role 注入，更精细的触发式召回仍在演进；
• /view 是只读 HTML 快照，不是完整 Web 控制台。

这些限制不是用来“免责声明式降调”，而是为了明确：当前版本哪些东西已经能够可靠运行，哪些仍属于下一阶段。

运行 Demo

env UV_CACHE_DIR=/tmp/aico-uv-cache uv run --python 3.11 aico-release-room-demo

项目地址：https://github.com/MarcelLeon/ai-company-os

我对下一阶段 Agent 应用的判断是：

真正会留下来的，不只是“能聊、能做一次任务”的 Agent，而是能被组织、被授权、被追踪、被复盘，并在人不在电脑前时继续推进项目的 Agent。

如果你的电脑里也同时跑着几个 AI CLI，我很好奇：你现在最缺的是更强的模型，还是一个真正能替你守住项目上下文的 Lead？

参考资料

• LangSmith / LangGraph Agent deployment：https://docs.langchain.com/langsmith/deployment
• CrewAI documentation：https://docs.crewai.com/
• Microsoft AutoGen documentation：https://microsoft.github.io/autogen/stable/

---

说明：本文由作者原创，并使用 AI 辅助进行结构调整和文字润色；观点、技术实现与事实边界由作者确认。