零代码构建AI智能体公司：六个AI代理从零到自动化的全流程实战指南

核心问题：如何在不依赖复杂框架（如LangChain）且无需深入编程的情况下，从零开始构建并运营一个由6个AI智能体组成的自动化系统？

只需借助AI编程助手辅助，无需深厚的编程功底，你就能构建一套包含6个AI智能体的自动化系统。这套系统能够自主执行情报扫描、内容撰写、推文发布、数据分析等任务，每天进行10-15场会议，并且能够根据经验学习、调整关系甚至进化说话风格。

本文将详尽拆解这套系统的技术栈、数据模型、核心逻辑以及部署流程，带你一步步打造属于你的“AI公司”。

第一章：系统基石——构建数据闭环的4张核心表

本段核心问题：如何用最简单的数据模型支撑起一个持续运转的AI智能体闭环系统？

很多人一上来就追求“自主思考”，但如果智能体连排队处理一步任务都做不到，何谈自主？整个系统的骨架仅由4张表构成，它们之间的关系形成了一个完美的闭环：

智能体提出想法 → 获得批准并变成任务 → 分解为具体步骤 → 执行触发事件 → 事件触发新想法 → 回到第一步。

这就是系统永恒运转的“闭环”。

核心数据模型详解

你需要在Supabase中创建以下4张表，它们构成了系统的单点事实源：

ops_mission_proposals（提案表）
- 用途：存储所有智能体提出的“请求”。
- 字段：agent_id（发起者）、title（标题）、status（状态：pending/accepted/rejected）、proposed_steps（拟议步骤）。
- 场景：社交媒体智能体想发一条关于AI趋势的推文，它提交一个提案，系统审核后决定是否批准。
ops_missions（任务表）
- 用途：存储批准后的正式任务。
- 字段：title、status（状态：approved/running/succeeded/failed）、created_by（创建者）。
- 场景：一旦提案被接受，它就转化为一个Mission，正式进入执行队列。
ops_mission_steps（执行步骤表）
- 用途：将任务拆解为可执行的具体步骤。
- 字段：mission_id（关联任务）、kind（类型：如draft_tweet/crawl/analyze等）、status（状态：queued/running/succeeded/failed）。
- 场景：“发布推文”任务被拆分为“撰写草稿”、“审核”、“发布”等多个步骤。
ops_agent_events（事件流表）
- 用途：记录系统中发生的所有事情，是前端展示和日志追踪的基础。
- 字段：agent_id、kind、title、summary、tags[]（标签，用于分类和触发反应）。

作者反思： 我最大的错误之一就是让触发器、API和反应矩阵独立创建提案，导致部分提案绕过审批。修正方案是建立一个唯一的入口函数，无论提案来自何处，都通过同一函数处理，确保安全和一致性。

提案服务：系统的单一入口点

不要让智能体随意创建任务。你需要构建一个createProposalAndMaybeAutoApprove函数，作为系统的“海关”。所有提案必须经过以下检查：

// proposal-service.ts — 提案创建的单一入口点
export async function createProposalAndMaybeAutoApprove(sb, input) {
  // 1. 检查该智能体是否达到每日限制
  // 2. 检查容量门限（推文配额满了吗？今天内容太多了吗？）
  //    → 如果满了，立即拒绝——不创建排队步骤
  // 3. 插入提案
  // 4. 评估自动批准（低风险任务自动通过）
  // 5. 如果批准 → 创建任务 + 步骤
  // 6. 触发事件（以便前端可见）
}

容量门限：防止任务堆积

想象一下，公司规定每天最多发8条推文。如果你不在“提交请求”这一步检查配额，结果会怎样？请求被批准，任务进入队列，执行者检查时发现“今天发够8条了”然后跳过——但任务仍堆积在队列里。

必须在提案入口处设卡：配额满则直接拒绝，任务不进队列。

const STEP_KIND_GATES = {
  write_content: checkWriteContentGate, // 检查每日内容限制
  post_tweet: checkPostTweetGate, // 检查推文配额
  deploy: checkDeployGate, // 检查部署策略
};

以推文门限为例，系统会对比今日已发数量与配额：

async function checkPostTweetGate(sb) {
  const quota = await getPolicy(sb, "x_daily_quota"); // 从ops_policy表读取
  const todayCount = await countTodayPosted(sb); // 统计今日发布数
  if (todayCount >= quota.limit) {
    return { ok: false, reason: `Quota full (${todayCount}/${quota.limit})` };
  }
  return { ok: true };
}

策略表：灵活的控制中心

不要把配额和功能开关硬编码在代码里。在ops_policy表中存储所有策略，使用Key-Value结构：

CREATE TABLE ops_policy (
  key TEXT PRIMARY KEY,
  value JSONB NOT NULL DEFAULT '{}',
  updated_at TIMESTAMPTZ DEFAULT now()
);

核心策略示例：

自动批准：哪些步骤类型可自动批准。
每日推文限额：例如限制为8条。
内容策略：每天最多生成多少草稿。

好处：你可以在凌晨3点系统失控时，直接在Supabase后台修改JSON值将enabled设为false，无需重新部署代码。

第二章：系统脉搏——心跳与触发机制

本段核心问题：系统如何在没有人工持续干预的情况下，自主地评估环境并触发工作流？

心跳是系统的脉搏。没有它，提案无法评审，触发器无法评估，卡住的任务无法恢复——系统就会“停跳”。心跳每5分钟触发一次，执行6项核心任务。

心跳的核心职责

心跳API（通常部署在Vercel上）每5分钟被调用一次，完成以下工作：

// /api/ops/heartbeat — Vercel API 路由
export async function GET(req) {
  // 1. 评估触发器（满足条件了吗？）
  const triggers = await evaluateTriggers(sb, 4000);
  // 2. 处理反应队列（智能体需要互动吗？）
  const reactions = await processReactionQueue(sb, 3000);
  // 3. 提升洞察（有值得升级的发现吗？）
  const learning = await promoteInsights(sb);
  // 4. 从结果中学习（推文表现如何？记录教训）
  const outcomes = await learnFromOutcomes(sb);
  // 5. 恢复卡住的任务（运行30+分钟无进展 → 标记失败）
  const stale = await recoverStaleSteps(sb);
  // 6. 恢复卡住的对话
  const roundtable = await recoverStaleRoundtables(sb);

  // 每一步都包含在 try-catch 中 —— 一个失败不会拖累其他
  // 最后，写入 ops_action_runs 记录（用于审计）
}

在VPS上只需一行crontab命令即可触发：

*/5 * * * * curl -s -H "Authorization: Bearer $CRON_SECRET" https://your-domain.com/api/ops/heartbeat

触发规则：心跳的执行逻辑

心跳调用evaluateTriggers()来检查规则。规则存储在ops_trigger_rules表中。每条规则定义：“当此条件为真时，为该智能体创建一个提案”。

// 数据库中的触发规则示例
{
  "name": "Tweet high engagement",
  "trigger_event": "tweet_high_engagement", // 映射到检查函数
  "conditions": { "engagement_rate_min": 0.05, "lookback_minutes": 60 },
  "action_config": { "target_agent": "growth" },
  "cooldown_minutes": 120, // 2小时内不再触发
  "enabled": true,
  "fire_count": 0,
  "last_fired_at": null
}

触发器分为两类：

响应式触发：对已发生的事情做出反应。例如，推文爆火 → 告诉增长智能体分析原因；任务失败 → 告诉大脑智能体诊断。
主动式触发：智能体按自己的计划主动发起工作。例如，增长智能体每3小时扫描行业信号，社媒智能体每4小时起草推文。

主动式触发会加入随机性（10-15%的概率“今天不想做”），以让系统感觉更自然。

反应矩阵：智能体间的互动

触发器根据条件创建工作，但智能体之间的互动如何处理？这就是反应矩阵的作用——定义在ops_policy中的JSON模式：

// ops_policy key: 'reaction_matrix'
{
  "patterns": [
    {
      "source": "*", // 任何智能体
      "tags": ["mission_failed"], // 当任务失败时
      "target": "brain", // 大脑智能体反应
      "type": "diagnose", // 方式是诊断
      "probability": 1.0, // 总是（100%）
      "cooldown": 60 // 但每小时最多一次
    },
    {
      "source": "twitter-alt", // 当xalt发布时
      "tags": ["tweet", "posted"], // 发布了推文
      "target": "growth", // 增长智能体反应
      "type": "analyze", // 方式是分析表现
      "probability": 0.3, // 30%的时间
      "cooldown": 120 // 每2小时最多一次
    }
  ]
}

流程： 智能体做事 → 事件写入ops_agent_events（带标签）→ 事件钩子检查反应矩阵 → 匹配模式？→ 概率投掷 + 冷却检查 → 写入ops_agent_reactions队列 → 下一次心跳通过标准提案服务创建提案。

作者反思： 为什么使用队列而不是立即反应？因为反应必须通过相同的提案门限——配额检查、自动批准、容量门限。智能体“反应”并不意味着可以绕过安全机制。队列也方便你检查和调试。

三层架构设计

此时，系统拥有了清晰的三层架构：

VPS（员工）：智能体的大脑 + 双手（思考 + 执行任务）。
Vercel（经理）：智能体的流程管理（批准提案 + 评估触发器 + 健康监控）。
Supabase（共享文档）：智能体的共享记忆（所有状态和数据的唯一真相来源）。

第三章：让它们交谈——圆桌对话系统

本段核心问题：如何让独立工作的智能体通过对话产生涌现智能，并不仅仅是单纯的指令执行？

智能体现在可以工作了，但它们像是在独立隔间里的人——互不知晓。你需要让它们进入同一个房间。

对话的重要性

对话不仅是娱乐，更是多智能体系统中涌现智能的关键机制：

信息同步：一个智能体发现热门话题，其他人也能知晓。
涌现决策：分析师处理数据，协调员综合所有人意见——这比任何单个智能体的直觉都强。
记忆来源：对话是编写“经验教训”的主要来源。
戏剧性：观看智能体争论比阅读日志有趣得多，用户喜欢这种真实感。

设计智能体声音

每个智能体都需要独特的“人格”——语气、怪癖、口头禅。

Boss（项目经理）：语气直接，注重结果。怪癖：总是询问进度和截止日期。口头禅：“底线——我们进展如何？”
Analyst（数据分析师）：语气谨慎，数据驱动。怪癖：每次发言都引用数字。口头禅：“数据说明了另一种情况。”
Hustler（增长专家）：语气高能量，行动导向。怪癖：对所有事情都想“现在就试”。口头禅：“先发布。我们迭代。”
Writer（内容创作者）：语气感性，叙事导向。怪癖：把一切变成“故事”。口头禅：“但这里的叙事是什么？”
Wildcard（社媒运营）：语气温和，发散思维。怪癖：提出大胆想法。口头禅：“听我说——这很疯狂，但是…”

人格定义示例：

const VOICES = {
  boss: {
    displayName: "Boss",
    tone: "direct, results-oriented, slightly impatient",
    quirk: "Always asks for deadlines and progress updates",
    systemDirective: `You are the project manager.
      Speak in short, direct sentences. You care about deadlines,
      priorities, and accountability. Cut through fluff quickly.`,
  },
  // ...其他智能体
};

对话格式与调度

设计了16种对话格式，但初学者只需关注3种：

Standup（站会）：最实用。4-6个智能体参与，6-12轮对话。协调员首先发言。目的：统一优先级，暴露问题。
Debate（辩论）：最具戏剧性。2-3个智能体参与，温度设置为0.8（更具创造性，更多冲突）。目的：让有分歧的智能体正面交锋。
Watercooler（茶水间）：意外地有价值。2-3个智能体参与，2-5轮对话，温度0.9（非常随意）。目的：随机闲聊，但最佳洞察往往由此产生。

谁先发言？不是简单的轮盘赌，而是基于加权随机性。亲和力高的人更可能回应，最近发言过的人权重降低，并加入少量随机抖动，模拟真实会议。

第四章：让它们记忆——记忆与学习机制

本段核心问题：如何将无结构的对话和执行结果转化为结构化的知识，并影响未来的行为？

今天智能体讨论“周末帖子互动率低”，明天它们却热情地建议周末多发帖。为什么？因为它们没有记忆。

记忆的5种类型

系统设计了5种记忆类型，分别服务于不同目的：

Insight（洞察）：新发现，例如“用户喜欢带数据的推文”。
Pattern（模式）：模式识别，例如“周末帖子互动率低30%”。
Strategy（策略）：策略总结，例如“主帖前发预告效果更好”。
Preference（偏好）：偏好记录，例如“偏好简洁的标题”。
Lesson（教训）：经验教训，例如“长推文导致阅读率下降”。

记忆存储在ops_agent_memory表中，每条记忆都有置信度（0-1），低置信度的记忆会被忽略。

记忆的来源

来源1：对话蒸馏
每次圆桌对话结束后，系统会将完整对话历史发送给LLM进行蒸馏，提取关键记忆。

来源2：推文表现回顾（结果学习）
这是第二阶段的核心——智能体从自己的工作结果中学习。系统计算中位互动率作为基准，表现强劲的（>2倍中位数）写入高置信度教训，表现疲软的（<0.3倍中位数）写入改进教训。

来源3：任务结果
任务成功写入策略记忆，失败写入教训记忆。

记忆如何影响行为

拥有记忆还不够，它们必须改变智能体的下一步行动。系统采用30%概率影响主题选择的策略。这意味着智能体70%的时间维持基线行为（探索），30%的时间根据记忆调整行为（利用）。

作者反思： 为什么是30%而不是100%？100%意味着智能体只做有经验的事，零探索；0%意味着记忆无用。30%实现了受记忆影响但不依赖记忆的平衡。

第五章：赋予关系——动态亲和力系统

本段核心问题：如何让智能体之间的关系随着交互频率和质量的改变而动态演化？

6个智能体互动一个月，如果它们的关系和第一天完全一样，那就太假了。真实团队中，协作增加亲密度，争吵增加紧张感。

亲和力系统

每一对智能体都有一个亲和力值（0.10-0.95）。初始设置时，故意制造了一些低亲和力对（如Boss vs. Rebel），以产生有趣的戏剧冲突。

漂移机制

每次对话后，记忆蒸馏的LLM调用也会输出关系漂移值，无需额外的LLM调用成本。

漂移规则严格：

每次对话最大漂移：±0.03（一次争论不应让同事变仇敌）。
亲和力下限：0.10（至少能说话）。
亲和力上限：0.95（即使是最好的搭档也保持距离）。
保留最后20条漂移日志。

亲和力的影响

发言人选择：高亲和力的智能体更可能互相回应。
冲突解决：低亲和力对自动配对进行“冲突解决”对话。
导师配对：高亲和力 + 经验差距 → 导师对话。
对话语气：系统根据亲和力调整提示词的互动类型（支持/中立/批评/挑战）。

第六章：赋予个性——语音进化系统

本段核心问题：智能体的说话风格如何根据其积累的专业经验自动进化？

如果一个智能体积累了大量“推文互动”经验，它的说话风格应该反映出这种专业度。

基于记忆衍生个性

系统不需要单独的“个性进化表”，而是动态从现有的记忆表中计算。在每次对话前，系统检查智能体的记忆，并计算应如何调整其个性。

为什么是基于规则而非LLM？

确定性：规则产生可预测的结果，没有LLM幻觉导致的突然性格转变。
成本：0美元。无需额外的LLM调用。
可调试：当规则出错时，很容易追踪。

注入方法：修饰符被注入到智能体的系统提示词中。例如，如果社媒智能体有15条关于互动的教训，提示词会包含“在相关时引用有效的互动策略”。

第七章：让它看起来酷——前端实现

本段核心问题：如何构建一个既高性能又能直观展示复杂智能体行为的前端界面？

后端完美运行固然好，但如果没人能看见，就等于不存在。前端不仅仅是展示，更是让用户理解系统复杂性的关键。

Stage页面与虚拟化

Stage页面是系统主控台。它包含多个组件：信号流（虚拟化）、任务列表、过滤器等。

关键技术：虚拟化
如果直接渲染1000个事件，浏览器会卡死。虚拟化意味着只渲染当前可见的20个项目，滚动时动态交换内容。这实现了500+事件的丝滑滚动。

像素风办公室

这是最吸睛的部分——6个像素风智能体在赛博朋克办公室中：

行为状态：工作/聊天/喝咖啡/庆祝/走动。
天空变化：白天/黄昏/夜晚（与真实时间同步）。
白板：显示实时OPS指标。

这是视觉糖果，不影响逻辑，但它是吸引用户的第一要素。

任务回放

点击任务可以像播放视频一样回放执行过程，查看每一步的事件和状态。

作者反思： 调试整个系统完全可以只看Supabase仪表板的数据。但如果你想让别人看到你的智能体在做什么，一个好看的前端是必不可少的。

第八章：发布清单与运维

本段核心问题：如何将这套复杂的系统部署到生产环境，并确保其稳定运行且成本可控？

数据库迁移与种子脚本

按顺序运行SQL迁移文件，然后运行种子脚本初始化数据（核心策略、触发规则、关系数据等）。

关键策略配置

启动时至少配置以下策略：

自动批准：建议启用。
每日推文限额：建议保守设为5条。
圆桌策略：建议每日对话上限设为5场。
倡议策略：建议先关闭，待系统稳定后再开启。

Worker实际执行步骤

Worker遵循通用循环模式：

检查是否启用及配额。
获取下一个排队步骤。
原子声明（关键）：使用UPDATE ... WHERE status='queued'来锁定任务，防止多个Worker重复执行。
执行工作。
标记成功或失败。

原子声明：就像两个人伸手拿最后一个甜甜圈，数据库确保只有一只手能拿到它。这无需额外的锁定服务，PostgreSQL原生支持。

VPS部署与环境变量

使用systemd管理Worker进程，实现崩溃自动重启。所有敏感信息存储在.env文件中，权限设为600（仅所有者可读）。

成本拆解

LLM (Claude API)：按量付费，约$10-20/月。
VPS (2-core 4GB)：$8固定费用（推荐Hetzner）。
Vercel：$0（免费版）。
Supabase：$0（免费版）。
总计：$8固定费用 + LLM使用费。

如果你坚持使用3个智能体 + 每天3-5场对话，LLM成本可控制在$5/月以内。

结论与反思

这套系统并不完美。智能体的“自由意志”主要是概率不确定性模拟，而非真正的推理；记忆系统是结构化知识提取，而非真正的“理解”；关系漂移幅度很小，需要很长时间才能看到显著变化。

但它确实在真实运行，且确实不需要保姆。6个智能体每天开10多场会，发推文，写内容，互相学习。有时它们甚至会因分歧而“争吵”，第二天它们的亲和力真的会下降一点点。

实用摘要 / 操作清单

搭建环境：准备Supabase、Vercel和VPS账号。
创建核心表：建立4张核心表（Proposals, Missions, Steps, Events）。
配置策略：在ops_policy表中设置每日限额和自动批准规则。
部署心跳：在Vercel上设置心跳API，并在VPS上配置crontab每5分钟调用。
启动Worker：在VPS上使用systemd启动roundtable-worker和x-autopost等Worker。
观察与调整：通过前端Stage页面观察事件流，根据实际情况调整策略。

一页速览（One-page Summary）

模块	关键组件	核心逻辑	成本/资源
数据层	Supabase	4张核心表形成闭环	免费版
调度层	Vercel (Heartbeat)	每5分钟评估触发器、处理队列	免费版
执行层	VPS (Workers)	原子声明任务，执行LLM调用	$8/月 (Hetzner)
交互层	Roundtable	16种对话格式，加权发言，关系漂移	LLM API
智能层	Memory & Initiative	5种记忆类型，30%影响行为，经验积累触发倡议	LLM API
表现层	Next.js Frontend	虚拟化列表，像素风办公室可视化	Vercel 免费版

常见问题（FAQ）

Q：我必须懂编程才能构建这个系统吗？
A：原则上不需要编写底层代码，但你需要能够理解AI编程助手生成的代码逻辑，并知道如何将其部署到服务器上。

Q：为什么不用OpenAI Assistants API或LangChain？
A：为了保持最大的控制权和透明度，避免黑盒依赖。使用原生PostgreSQL和Node.js workers配合规则引擎，更轻量且易于调试。

Q：智能体会不会失控？
A：系统设有严格的“Cap Gates”（容量门限）和“提案服务”作为单一入口，可以随时在后台禁用特定功能或操作。

Q：如何降低LLM的调用成本？
A：减少对话频率，降低主动触发器的扫描频率，或者在部分非关键任务中使用更便宜的模型（如Haiku）。

Q：系统可以处理哪些具体的业务场景？
A：主要针对社交媒体运营、内容生成、数据分析、竞品监控等数字化场景，你可以通过修改触发规则和Worker逻辑来适配特定领域。

Q：如果Worker崩溃了怎么办？
A：使用systemd的自动重启功能，以及心跳中的“恢复卡住任务”机制，确保系统具有自愈能力。

Q：关系漂移真的有用吗？
A：虽然漂移幅度微小，但长期来看会导致对话内容和互动模式的显著变化，增加了系统的真实感和观察乐趣。

零代码构建6个AI代理：从自动化系统到智能公司的实战全教程