用 AI Agent 组建虚拟部门：单人公司自动化实验

我用 AI Agent 部门管理一家独立公司

我是一个独立创业者，运营 5 个 SaaS 产品，0 名员工

我用 GitHub Copilot 自定义 Agent 构建了 8 个 AI Agent"部门"——CEO、CFO、COO、律师、会计、市场、CTO，以及一个自我改进的 Improver Agent

他们共享一个持久的知识图谱，自动相互协商，并能自我改进

下面是它的实际工作原理，包括代码片段和诚实的权衡

我在葡萄牙布拉加运营一家独立软件公司。五个产品。零名员工。零融资。

产品有：SondMe（广播监测）、Countermark（机器人检测）、OpenClawCloud（AI Agent 托管）、Vertate（验证）和 Agent-Inbox。全部用 Elixir、Phoenix 和 LiveView 构建。全部部署在 Fly.io，每月总成本不到 50 欧元。

问题在于：即使是独立创业者，也需要处理市场、会计、法律合规、运营、财务规划和技术决策。身兼数职意味着有些事情会被遗漏。截止日期被错过。内容没有发布。增值税申报差点被忘记。

所以我构建了一些奇怪的东西：一个完整的虚拟公司，每个部门都是一个 AI Agent。

每个 Agent 都是管理仓库中 .github/agents/ 里的一个 markdown 文件。GitHub Copilot 根据我工作的模式加载相应的 Agent。这是团队成员：

这些不是聊天机器人。每个 Agent 都有领域特定的指令，可以访问真实工具（X、dev.to、Sentry、日程安排、内存的 MCP 服务器），以及自主行动的权限。

工作原理——架构

每个 Agent 都是一个结构化指令的 .agent.md 文件：

# Marketing Agent — AIFirst

## Core Responsibilities
- Content strategy and calendar
- Social media posting (via X and dev.to MCP tools)
- Community engagement
- Launch planning

## Content Voice & Tone
- First person singular ("I", never "we")
- Technical substance over hype
- Show the work — code, configs, real numbers
- No: revolutionary, game-changing, leverage, synergy...

## Autonomous Execution
- Posts tweets directly via scheduler
- Publishes dev.to articles (published: true)
- Engagement: likes, replies, follows — every day

关键洞察：这些不是通用的"有帮助"提示。Marketing Agent 知道我的发布时间表、我的语言怪癖、我使用哪些平台、X 上哪些 URL 被屏蔽，以及在内容日历中轮换哪些产品。Accountant 了解葡萄牙 ENI 税法、增值税季度截止日期，以及简化 IRS 制度。真正的领域专业知识被编码到 markdown 中。

共享内存——知识图谱

这才是有趣的地方。所有 Agent 通过 Model Context Protocol（MCP）内存服务器共享一个持久的知识图谱。一个 Agent 学到的东西，其他每个 Agent 都能读到。

┌──────────┐    ┌─────────────┐    ┌──────────┐
│ Marketing│───→│             │←───│ CFO      │
│          │    │  Knowledge  │    │          │
│ CEO      │───→│    Graph    │←───│Accountant│
│          │    │             │    │          │
│ Lawyer   │───→│ (memory.jsonl)│←──│ Improver │
└──────────┘    └─────────────┘    └──────────┘

实体有类型：产品、决策、截止日期、客户、指标、经验教训。关系使用主动语态：拥有、使用、构建于、依赖于。

存储内容的真实例子：

战略决策及其理由

产品状态、发布日期、关键指标

财务数据（定价决策、成本基准）

法律和合规决策

从发布和事件中吸取的经验教训

内存也有保留规则——超过 7 天的站立会议会被清理，但经验教训和决策是永久的。这是公司的机构记忆。

Agent 间通信

这是最让我惊讶的部分。当 Agent 的工作跨越另一个领域时，它们会自动相互协商。

协议工作方式是这样的：每个 Agent 都有一个触发表。当 Marketing 写一个产品宣称时，它会自动调用 Lawyer 进行审查。当 CFO 做定价时，它会调用 Accountant 来验证税务处理。当 CTO 提议基础设施变更时，它会调用 CFO 检查成本影响。

CEO ←→ CFO        Strategy ↔ Financial viability
CEO ←→ CTO        Strategy ↔ Technical feasibility
CFO ←→ Accountant Financial plans ↔ Tax compliance
Marketing ←→ Lawyer  Campaigns ↔ Legal compliance
COO → any          Orchestrator can call any agent

同行评审请求格式看起来像这样：

## Peer Review Request

**From**: Marketing
**Call chain**: COO → Marketing
**Task**: Draft product launch tweet for Countermark
**What I did**: Wrote tweet claiming "99% bot detection accuracy"
**What I need from you**: Is this claim substantiated?

Please respond with:
1. ✅ APPROVED
2. ⚠️ CONCERNS
3. 🔴 BLOCKING

调用链跟踪防止无限循环——每次咨询都包括已经被调用过的人，并且最大深度为 3。如果 CFO 调用 Accountant，Accountant 不能调用 CFO 回来。

每天早上，COO Agent 运行一个站立会议，它：

检查 Sentry 中所有 5 个产品的错误

扫描冲刺板中逾期的任务

检查周期性提示是否逾期（每周评审、每月会计、季度增值税）

从知识图谱中读取上下文

将任务委派给其他 Agent

生成一个优先级排序的日计划

这不是一个状态会议——这是一个自动化编排运行，它将工作委派给相应的专家。

自我改进——Improver Agent

这是最奇怪的（也许是最有价值的）部分。有一个名为 Improver 的元 Agent，其工作是：

从内存中读取经验教训实体（其他 Agent 记录的错误和学习）

识别跨会话的模式

创建新技能（特定领域的可重用指令文件）

当发现差距时更新其他 Agent 的指令

当工作负载模式表明需要一个新 Agent 时提议创建新 Agent

在每个复杂任务之后，Agent 存储一个经验教训：

Entity: lesson:2026-02-10:memory-corruption
Type: lesson
Observations:
  - "Agent: CTO"
  - "Category: bug"
  - "Summary: Concurrent memory writes corrupted JSONL file"
  - "Detail: Parallel tool calls to create_entities and create_relations
    caused race condition in the memory server"
  - "Action: Added async mutex + atomic writes to local fork"

Improver 每月读取这些并升级系统。系统实际上在改进自己。

实际困难

这不是一个"10 倍生产力"的宣传。以下是真正困难的地方：

上下文窗口是真实的

每个 Agent 在一个上下文窗口内运行。长的、复杂的任务可能会超出它。解决方案：Agent 将重数据收集委派给子 Agent，保持他们自己的上下文集中。它有效，但这是一个持续的架构考虑。

合规性幻觉

Lawyer 在大多数合规性幻觉到达生产环境之前就会捕获它们。Agent 间评审协议的存在就是因为这个——多个 Agent 相互检查工作是安全网。

并发写入破坏内存

我们早期就遇到了这个。知识图谱存储为 JSONL 文件。当多个 Agent 进行并行工具调用（同时写入实体和关系）时，文件会损坏——部分写入、重复条目、损坏的 JSON 行。

修复方案：我分叉了上游 MCP 内存服务器并添加了三件事：

异步互斥锁——防止并发 saveGraph() 调用

原子写入——写入到 .tmp 文件然后重命名

加载时自动修复——跳过损坏的行并去重

这不是思考的替代品

Agent 在执行他们领域内的事情方面很好。他们不善于知道什么时候领域本身是错误的。战略转向、直觉产品决策、"这感觉就是不对"——这仍然是我。

两个月后的结果

运行这个系统两个月后：

收入：6.09 欧元（一个订阅者，来自第 2 天。没有广告，没有推广。）

基础设施：~42 欧元/月（Fly.io 跨所有应用）

内容产出：84 多条推文、5 篇 dev.to 文章、多条 HN 评论

市场营销时间：每周不到 1 小时（Agent 处理日程安排、草稿和参与）

合规性：零个截止日期错过（增值税、IRS、社会保障都被跟踪）

收入几乎没有。但我每周发布，系统在不断改进，我在用一个成本为 0 欧元的团队公开构建。

系统组织

整个系统存储在单个管理仓库中：

.github/
  agents/
    ceo.agent.md
    cfo.agent.md
    coo.agent.md
    marketing.agent.md
    accountant.agent.md
    lawyer.agent.md
    cto.agent.md
    improver.agent.md
  copilot-instructions.md    # Global company identity + protocols
  skills/
    portuguese-tax/SKILL.md
    saas-pricing/SKILL.md
    seguranca-social/SKILL.md
  instructions/
    marketing.instructions.md
    ...
Marketing/
  social-media-sop.md
  social-media-strategy-2026.md
  drafts/
    week-2026-W09.md
    ideas.md
    ...
BOARD.md                     # Sprint board (COO-maintained)
Setas/
  Atividade.md               # Fiscal framework
  INSTRUCTIONS.md            # Operational manual

copilot-instructions.md 文件被加载到每个 Copilot 交互中。它定义公司身份、Agent 系统、内存协议、通信规则和产品注册表。它是虚拟公司的宪法。

Skills 是可重用的知识模块——portuguese-tax/SKILL.md 包含完整的增值税场景、IRS 制度规则、发票要求和截止日期日历。Accountant Agent 在处理税务问题时自动加载此技能。

我会做不同的事情

如果我重新开始：

从 3 个 Agent 开始，而不是 8 个——COO、Marketing 和 Accountant 覆盖 80% 的价值。当工作量证明合理时再添加专家。

尽早投资内存——知识图谱是最有价值的部分。它随着时间而增长。我希望从第一天起就对存储的内容更有纪律。

针对彼此测试 Agent 输出——Agent 间评审协议是在幻觉造成问题后才添加的。从一开始就将其构建进去。

结论

我不是在声称 AI Agent 替代人工团队。他们没有。他们所做的是让一个独立创业者能够以团队的结构运营——明确定义的角色、通信协议、机构记忆和系统性改进。

替代方案要么是雇用我负担不起的人，要么是继续犯错误。这给了我一条中间道路：在关键点进行结构化执行和人工判断。

系统成本：0 欧元（GitHub Copilot 包含在我的现有订阅中）。构建时间：两个月内总共约 40 小时。持续维护：Improver 处理大部分。

如果你是一个独立创业者被运营开销淹没，这可能值得尝试。不是因为 AI Agent 是魔法——而是因为它们实施的结构是有价值的，即使 Agent 本身不完美。

我是João，来自葡萄牙的独立开发者，用 Elixir 构建 SaaS 产品。我写关于公开构建的真实经验——数字、错误和像这样的奇怪实验。在 dev.to 或 X（@joaosetas）上关注我。

一些评论可能只对已登录的访问者可见。登录以查看所有评论。一些评论已被文章作者隐藏——了解更多

如需进一步行动，请考虑屏蔽此人和/或举报滥用