One AI, six jobs: how I take an idea from a one-line thought to something live, with a team of agents that share a task board

一个 AI，六种职能：我是如何通过一个共享任务看板的智能体团队，将一个想法从一句话变成现实的

I don’t have a chatbot in my homelab. I have a staff. It’s one self-hosted AI agent, but it runs as a set of profiles — a chief of staff, a builder, a researcher, a writer, a security reviewer, an infrastructure admin — each with its own system prompt, its own tools, and its own model, all sharing a single task board. 我的家庭实验室里没有聊天机器人，我拥有一支“员工团队”。这其实是一个自托管的 AI 智能体，但它以一组配置文件的形式运行——包括幕僚长、构建者、研究员、撰稿人、安全审查员和基础设施管理员。每个角色都有自己的系统提示词、工具和模型，并且共享同一个任务看板。

When I have an idea, I don’t sit down and build it. I hand it to the team, and the team moves it along a pipeline until it’s live. This post is how that actually works: the roles, the board, the one rule that keeps the whole thing honest, and a real walk from “I wonder if…” to “it’s published.” It’s less a tutorial than a description of a shape you can copy with whatever agent framework you like — the interesting part isn’t the tooling, it’s the division of labour. 当我有一个想法时，我不会亲自坐下来去实现它。我把它交给团队，团队会沿着流水线推进，直到它上线。这篇文章将介绍其运作方式：角色分配、看板管理、确保系统诚实运行的一条准则，以及从“我想试试……”到“正式发布”的真实过程。与其说这是一篇教程，不如说它描述了一种你可以用任何智能体框架复制的模式——有趣的部分不在于工具，而在于分工。

The roster

团队成员

Six profiles. Each knows one job and is deliberately bad at the others. 六个配置文件。每个角色只专注于一项工作，并刻意避开其他职能。

Chief of staff — the default. Doesn’t build or research; it routes. Takes a vague idea, breaks it into cards, decides which profile each card belongs to, and reads the results back to me in the morning. It’s the only one that talks to me by default. 幕僚长（默认角色）： 不负责构建或研究，只负责调度。它接收模糊的想法，将其拆解为任务卡片，决定每张卡片归属哪个角色，并在每天早上向我汇报结果。它是唯一默认与我沟通的角色。
Scout — research. Web search, its own email inbox, the estate’s knowledge base. It gathers facts and writes them down. It never builds and never decides. 侦察员（研究）： 负责网络搜索、管理自己的电子邮箱以及访问知识库。它只负责收集事实并记录下来，从不参与构建，也不做决策。
Builder — code. Writes the thing, runs it, iterates. Has the infrastructure tools; the others mostly don’t. 构建者（代码）： 负责编写、运行和迭代代码。它拥有基础设施工具，而其他角色通常没有。
Security — the adversary. Its whole job is to try to break what the builder made and to refuse to be reassured. It reports findings; it doesn’t fix them (that goes back to the builder as a new card), because the reviewer and the author being the same agent is how you get a review that says “looks good.” 安全审查员（对手）： 它的全部工作就是试图破坏构建者做出的成果，并且拒绝被轻易说服。它只报告发现的问题，而不负责修复（修复工作会作为新卡片回到构建者手中），因为如果审查者和作者是同一个智能体，你只会得到“看起来不错”这种敷衍的评价。
Writer — documentation and publishing. Turns a finished thing into a README, a post, a PDF. Crucially, it’s handed the facts; it does not invent them. 撰稿人（文档与发布）： 将成品转化为 README、文章或 PDF。关键在于，它只处理被提供的事实，绝不编造。
IT admin — the caretaker. Patching, capacity, drift, backups. Not part of the idea pipeline, but it’s the reason the pipeline has somewhere stable to run. IT 管理员（维护者）： 负责打补丁、容量管理、配置漂移监控和备份。它不参与想法的流水线，但它是流水线能够稳定运行的基础。

The reason to split one capable model into six narrow ones isn’t performance. It’s accountability. A single agent told to “research this, build it, check it’s secure, and write it up” will do all four in the same breath and grade its own homework on every one. Six agents that hand work to each other across a board can’t — each step has a different author, and a handoff is a natural place to check the work. 将一个强大的模型拆分为六个单一职能模型的理由不是性能，而是责任制。如果让一个智能体“研究、构建、检查安全并撰写文档”，它会一气呵成并给自己打满分。而六个通过看板交接工作的智能体则无法做到这一点——每一步都有不同的作者，而交接过程本身就是检查工作的天然关卡。

The board is the whole trick

看板是核心秘诀

The profiles don’t call each other. They share a Kanban board, and that indirection is what makes it a team instead of a pile of prompts. An idea becomes a card. A card has an owner (which profile) and a column (what stage). When the builder finishes, it doesn’t “call the security agent” — it moves the card to review and drops it. The security profile, on its own schedule, picks up whatever’s sitting in review. Findings become new cards in to-build, owned by the builder. When there’s nothing left in flight, the writer’s cards in to-publish come up. 这些配置文件之间不会互相调用。它们共享一个看板，这种间接性使它们成为一个团队，而不是一堆提示词的堆砌。一个想法变成一张卡片。卡片有所有者（哪个角色）和列（所处阶段）。当构建者完成工作时，它不会“呼叫安全智能体”，而是将卡片移动到“审查”列并放下。安全角色会根据自己的节奏，处理“审查”列中的任务。发现的问题会变成新的“待构建”卡片，由构建者负责。当没有正在进行的工作时，撰稿人的“待发布”卡片就会被处理。

Three things fall out of doing it this way, and all three matter: 这样做有三个好处，且都至关重要：

Nothing is lost when an agent stops. The state lives on the board, not in a conversation. An agent can crash, be restarted, be swapped for a better model — the work is still sitting in its column. 智能体停止工作时不会丢失任何东西。 状态保存在看板上，而不是对话中。智能体可以崩溃、重启或更换为更好的模型，工作依然在它的列中。
I can see it. The board is the same board a human team would use. At any moment I can look at what’s in review, what’s blocked, what shipped. 我能看到一切。 这个看板与人类团队使用的完全一样。我随时可以查看哪些在审查中、哪些被阻塞、哪些已发布。
The handoffs are inspectable. Every transition is a place I could put a gate — and for anything that touches the outside world, I do. 交接过程可审计。 每一个转换环节都是我可以设置关卡的地方——对于任何涉及外部世界的内容，我都会这样做。

The one rule that keeps it honest

确保诚实的一条准则

Here is the rule the entire estate is built on, learned the expensive way: Scripts gather facts. Models never do. 这是整个系统建立的基础准则，是我通过惨痛教训学到的：脚本负责收集事实，模型绝不负责。

I used to let the research profile go and find things — market demand, system health, “opportunities.” It hallucinated with total confidence: it cited demand on forums it invented, reported backups that hadn’t run as successful, and once appended a “[SILENT]” tag to a report while breaking the very instruction that tag referred to. A model asked to gather a fact will, under the slightest ambiguity, make one up and present it as certain. 我曾经让研究角色去寻找信息——市场需求、系统健康状况、“机会”等。它会极其自信地产生幻觉：引用它虚构的论坛需求，报告从未运行成功的备份，甚至在报告中加上“[静默]”标签的同时，却违反了该标签所指的指令。当模型被要求收集事实时，只要稍有歧义，它就会编造一个事实并将其呈现为确凿无疑。

So the division of labour has a hard edge in it: the deterministic parts gather; the model parts phrase. A monitoring script queries the real state and writes down real numbers. Then the writer profile is handed those numbers to turn into prose, and is forbidden to add any of its own. The clever, non-deterministic layer is allowed to rank, route, and write — it is never the thing that counts or decides something I can’t reproduce. 因此，分工中有一条硬性界限：确定性的部分负责收集，模型部分负责润色。监控脚本查询真实状态并记录真实数据，然后将这些数据交给撰稿人角色转化为文字，并禁止其添加任何额外内容。智能的、非确定性的层级可以进行排序、路由和写作，但绝不能让它去计算或决定我无法复现的事情。

A guardrail in a prompt is a suggestion. A guardrail in a function is a wall. 提示词中的护栏只是建议，函数中的护栏才是围墙。

A real run: idea to live

真实案例：从想法到上线

Here’s the shape of an actual pass through the pipeline — the one that produced the thing you might have arrived here from. 以下是流水线实际运行的一个案例——也就是你现在阅读的这篇文章的产出过程。

The idea, in one line: “Write up what I learned from the trading bots that kept reporting success while doing nothing, and put it somewhere people can read it.” That’s all I gave it. 想法只有一行：“写下我从那些一直报告成功却什么都没做的交易机器人身上学到的东西，并发布到人们可以阅读的地方。”这就是我给它的全部指令。

Here’s what the team did with it: 团队的操作如下：

Chief of staff broke it into cards: dig up the real numbers from the project (scout), draft the post (writer), build a PDF version (builder), check it for anything that shouldn’t be public (security), publish (writer). 幕僚长将其拆解为卡片：从项目中挖掘真实数据（侦察员）、起草文章（撰稿人）、构建 PDF 版本（构建者）、检查是否有不宜公开的内容（安全审查员）、发布（撰稿人）。
Scout pulled the actual figures — the real losses, the specific bugs, the exact failure signatures — from the project’s own logs and notes, and wrote them to a facts file. Not “roughly what happened,” the numbers. 侦察员从项目的日志和笔记中提取了实际数据——真实的损失、具体的 Bug、确切的故障特征——并将其写入事实文件。不是“大概发生了什么”，而是确切的数字。
Writer took only that facts file and drafted the post. Because it was handed the facts, it couldn’t drift into a better-sounding story that wasn’t true. 撰稿人仅根据该事实文件起草了文章。因为它被直接提供了事实，所以无法编造出听起来更好但并不真实的故事。
Builder rendered a longer version to a PDF… 构建者将长版本渲染为 PDF……