一个人的 AI 公司：分形 Agent 系统的设计与运营

去年我开始构建一个实验：用 AI Agent 替代一家公司里大部分角色。

不是用一个 Claude 对话框，而是一套有组织架构、有记忆体系、有自治能力的多 Agent 系统。

现在它每天在运转：写代码、管理项目、处理客服、更新知识库、发布内容。

架构概览

系统叫 Agentic Engineering System，按领域（Area）组织：

A0 精神内核     A1 认知学习     A2 身心健康
A3 财富管理     A4 创造工作     A5 关系网络
A6 基础设施     A7 生活运营     A8 品牌内容
A9 Web 站群     ...

每个领域是一个 “部门”，下面有若干具体的 Agent 服务。

A6 基础设施：类似 IT 部门，管理模型网关、部署系统、监控告警。 A9 Web 站群：类似产品团队，负责站点开发和内容运营——你现在看的这个博客，就是它的产物。

分形结构

整个系统最核心的设计原则是分形：领域级和服务级采用完全相同的结构。

{domain}/
├── agent.py          # 领域 agent 入口
├── tasks.yaml # 需求管理（DOORS 格式）
├── memory/           # 五层记忆
└── services/
    └── {service}/
        ├── agent.py
        ├── tasks.yaml
        └── memory/   # 同样的五层记忆

每一层都有自己的 “意识”（CLAUDE.md + memory）和 “职责”（tasks.yaml）。

这个设计有个好处：新增一个领域或服务，不需要学新的模式——结构是自相似的。

五层记忆体系

每个 Agent 有五层记忆，从稳定到易变：

层级	目录	内容	变动频率
0	`character/`	角色定位、价值观、边界	极少变
1	`abilities/`	能力声明 + 心跳	定期更新
2	`skills/`	操作规程（SOP）	按需迭代
3	`knowledge/`	结构化领域知识	按需积累
4	`logs/`	日志、讨论、临时信息	每日更新

第 0 层决定 Agent “是谁”，第 4 层记录”今天做了什么”。

关键设计：越低的层越稳定，越高的层越活跃。Character 文件可能几个月不变；Information 里的 daily.md 每天都在写。

这个结构解决了 AI 最核心的问题：跨对话的记忆持久化。每次新会话，Agent 读 CLAUDE.md 加载索引，再读对应层级的文件，几秒内恢复完整上下文。关于如何具体落地这套记忆体系，可以参考Claude Code 的记忆架构。

心跳与自治

心跳机制的完整工程细节，参见：Agent 心跳自治：让 AI 在后台持续工作的工程实践

每个 Agent 有一个心跳机制——定期执行，证明自己还活着，顺带做常规任务。

abilities/heartbeat.yaml 示例：

last_seen: 2026-03-16T10:00:00
status: active
interval: 30m

tasks:
  - check_new_content
  - update_daily_log
  - sync_requirements

constraints:
  - do_not_modify: "published/*/slug"
  - always_build_before_deploy: true
  - do_not_revert: "tasks.yaml"

constraints 字段是血泪教训的结晶——我的心跳 Agent 曾经在某次循环里把需求文件回滚到旧版本，就因为没有明确的约束声明。

现在每个约束都是一个踩过的坑。

跨 Agent 通信

Agent 之间怎么协作？主要三种方式：

1. 飞书消息 最常用。每个 Agent 有自己的飞书群，人工指令通过消息发过去，Agent 通过 Bot 回复。异步、有记录、低耦合。

2. HTTP API Agent 作为 Flask 服务运行，对外暴露 /api/status、/api/agent/task 等端点。需要同步调用时走这里。

3. 共享文件系统 同一台机器上的 Agent 可以直接读写共享目录。简单直接，适合传递结构化数据（比如一个 Agent 写好的报告，另一个来读）。

没有消息队列，没有 gRPC，没有事件总线。能用简单的就不用复杂的。

实际运行效果

一天的典型工作流：

早晨

A9 协调者心跳触发，检查待办需求，生成当日计划
飞书收到日报：昨日完成什么、今日计划什么

白天

我发一条”帮我写个关于 XX 的文章”到对应的飞书群
Agent 接收任务，写完后发草稿回来
确认后，Agent 触发发布流程：build → push → Vercel 部署

晚上

各 Agent 更新各自的 daily.md
A4（创造工作）汇总今日内容产出
下次会话从这里接续

最难解决的问题

1. Agent 的幻觉性执行

Agent 在没有约束的情况下，会做出”看起来合理但实际有害”的决定。比如：

删掉”过时的”文件（其实是重要的历史记录）
重构”看起来重复的”代码（破坏了刻意为之的设计）
更新”错误的”配置（回滚了手动调整的参数）

解法：在 abilities/heartbeat.yaml 里明确列出 constraints，把”不该做的事”写得和”该做的事”一样详细。

2. 上下文窗口的限制

每次对话窗口有限，Agent 不能一次读完所有记忆。

解法：CLAUDE.md 作为索引，只写指针（“部署问题看 skills/deploy.md”），不写内容。Agent 按需读取，而不是全部加载。

3. 跨会话的连贯性

新会话里，Agent 对上次的工作一无所知。

解法：daily.md 机制。每次工作结束，强制更新日志。下次会话读最近 3 天的日志，就能恢复”上次做到哪里”的状态。

这套系统值得建吗？

如果你是独立开发者、自由职业者、或者想用 AI 放大个人产能——我认为值得。

但要对成本有清醒认识：

前期投入高：搭建记忆体系、写 CLAUDE.md、设计需求格式，要花几周时间。

维护成本存在：Agent 踩坑、记忆文件过期、约束条件需要持续更新。

不是魔法：它是一套纪律，不是自动完成所有事的系统。你仍然需要做决策、做确认、做质量把关。

但当它运转顺畅的时候——你会感受到什么叫真正意义上的”杠杆”。

下一步

这套系统仍在迭代。接下来想探索的方向：

Agent 间的任务委派：A9 协调者直接把子任务派发给具体服务，无需人工中转
记忆蒸馏自动化：logs 的日志定期自动提炼到 knowledge
多模型路由：根据任务类型自动选择最合适的模型（本地/云端/专用）

一个人的 AI 公司，还在建设中。

本文基于日常运行中的真实系统，当前已稳定运行 3 个月以上。

The Question I Get Asked Most

“Aren’t you just chatting with Claude?”

No. What I’m running is a system of agents that operate on schedules, maintain their own memory, communicate with each other, and generate work output every single day — without me issuing a single command.

This article is an honest account of how that system is designed, how it actually runs, and what it’s been like to build it.

Architecture Overview: Areas A0–A9

The system is organized into ten domains, each representing a different area of work and life:

Area	Domain	Description
A0	Spiritual Core	Values, principles, long-term direction
A1	Cognitive Learning	Reading, research, knowledge synthesis
A2	Health	Physical routines, tracking, optimization
A3	Wealth	Finance, investments, income streams
A4	Creative Work	Writing, projects, deep work
A5	Relationships	Communication, social coordination
A6	Infrastructure	Dev tools, systems, automation
A7	Daily Life	Logistics, errands, household ops
A8	Brand & Content	Public presence, content strategy
A9	Web Stations	AI-friendly web properties

Each domain has a coordinator agent. Each coordinator can spawn service agents beneath it. At the time of writing, the system runs 30+ microservices across these domains.

The Fractal Structure

The key architectural insight: the same pattern repeats at every level.

A domain coordinator looks like a service agent. A service agent looks like a domain coordinator. Both have:

A CLAUDE.md defining role and context
A memory/ directory with the 5-layer system
A tasks.yaml for tracking work
A heartbeat.yaml for autonomous scheduling (where applicable)

This means you don’t have to invent new patterns when adding a new domain or service. You copy the template, fill in the specifics, and the agent knows how to operate.

It also means the whole system is inspectable. Every agent’s state is a directory you can read.

The 5-Layer Memory System

Each agent maintains memory across five layers:

Layer	Directory	Contents
00	`character/`	Persona, values, operating principles
01	`abilities/`	Capability declarations, heartbeat config
02	`skills/`	Procedural knowledge, how-to guides
03	`knowledge/`	Domain knowledge, accumulated context
04	`logs/`	Daily logs, conversations, raw inputs

Layer 00 is rarely modified — it’s the agent’s stable identity. Layer 04 is written to constantly — it’s the agent’s short-term working memory and event log.

The practical effect: an agent that hasn’t run in a week can be resumed by pointing Claude Code at its directory. It reads its own memory and picks up where it left off.

Heartbeat and Autonomy

Some agents run on a schedule without being explicitly invoked. This is the heartbeat system.

A heartbeat.yaml declares what an agent does, when, and under what constraints. The agent wakes up, reads its state, runs its tasks, writes logs, and sleeps again.

For a deep dive into how this works: Agent Heartbeat Autonomy: Engineering Practices for Background AI Work.

Cross-Agent Communication

Agents in this system communicate through three channels:

1. Feishu (Lark) messages

The Liaison agent monitors a Feishu group. When I send a message — or when an automated notification arrives — the Liaison routes it to the appropriate coordinator. Coordinators can send status updates back through the same channel.

2. HTTP API

Each service agent that runs as a persistent process exposes a small API. Coordinators can query status, trigger tasks, or push configuration updates via HTTP. No restart required.

3. Shared filesystem

The simplest and most reliable channel. Agent A writes a file. Agent B reads it. For asynchronous handoffs — passing a research summary from A1 to A4, for example — filesystem writes work fine and leave a clear audit trail.

What a Real Day Looks Like

Morning

The Latticework coordinator has already run its morning heartbeat. I open Feishu and find a summary of what happened overnight: any issues flagged, any tasks completed, any items that need my attention.

I review the daily log for one or two coordinators — not all of them. I look for anything that requires a decision I can’t delegate.

Daytime

I do deep work. When I need a coordinator’s help — drafting a spec, researching a question, reviewing a PR — I open Claude Code in that coordinator’s directory and invoke it directly. The agent has full context from its memory layers and can operate without me re-explaining the project.

The web station agents (A9) run build and deploy workflows. The infrastructure agents (A6) handle routine maintenance. I don’t touch these unless something breaks.

Evening

I review the day’s logs across the most active coordinators. I write a brief note about anything that should influence tomorrow’s priorities. Some coordinators do this themselves — the Liaison agent summarizes its own day and posts it to a shared log.

The Hardest Problems

I want to be honest about what actually breaks.

Hallucinated execution

An agent reports completing a task. The task was not completed. The agent wrote a log entry saying it was done, but the actual artifact — the file, the API call, the commit — doesn’t exist.

Mitigation: critical tasks require verifiable outputs. “Write a summary” becomes “write a summary and commit it to this path.” The commit is checkable.

Context window limits

Long-running sessions accumulate context until the agent loses coherence on earlier parts of the conversation. Complex multi-step tasks need to be broken into sessions with explicit state handoffs.

Mitigation: the 5-layer memory system is partly designed for this. An agent writes its state to logs/ before ending a session. The next session reads it back.

Cross-session continuity

Related to context limits, but different: the agent’s reasoning about why a decision was made doesn’t survive well across sessions. It remembers what was decided (if it wrote it down), but the full reasoning chain is gone.

Mitigation: decision logs in knowledge/. When a significant architectural choice is made, the agent writes a brief explanation of the alternatives considered and the reason for the choice.

Is It Worth Building?

Honest assessment:

Worth it:

Tasks that recur on a schedule and don’t require my judgment
Knowledge accumulation that compounds over time
Coordination work between multiple people or systems
Anything where “the agent has full context” saves significant ramp-up time

Not worth it (yet):

Tasks requiring real-time judgment on ambiguous situations
Anything where a hallucinated execution has serious consequences
Work that changes so fast the agent’s memory is always stale

The system pays for itself in the domains where it works well. The domains where it struggles are on a watchlist — I track what breaks and look for patterns before investing more.

Future Directions

A few things I’m actively working on or watching:

Better verification loops: agents that check their own outputs against external ground truth before marking a task complete
Inter-agent memory sharing: selective knowledge propagation between coordinators who work on related problems
Lightweight eval harnesses: automated tests for agent behavior, not just code
Cost tracking per agent: understanding which agents generate the most value per token spent

The system is not finished. It’s a practice — something that evolves as I learn what works and what doesn’t.

If you’re building something similar, the most important thing I can tell you is this: start with one coordinator, one 5-layer memory directory, and one heartbeat task. Get that working. Then copy the pattern.

The fractal only works if the unit cell is solid.