# Wu-Tang Forever: My Hermes Multi-Agent Setup Ain’t Nuthin’ to F*ck With
**作者**: Tony Simons
**日期**: 2026-05-06T13:12:06.000Z
**来源**: [https://x.com/tonysimons_/status/2081054380241879425](https://x.com/tonysimons_/status/2081054380241879425)
---
Everybody wants a multi-agent setup now.
A researcher.
A coder.
A writer.
A reviewer.
A browser agent.
A project manager.
Maybe a few subagents floating around for good measure.
It sounds powerful as hell, until you actually try to run one.
Then you realize you’ve basically built an AI office where everybody has the same keys, nobody knows who owns the task, three agents are touching the same file, and the “manager” keeps doing all the work anyway.
I just finished rebuilding my entire Hermes Agent setup around a proper multi-profile architecture.
Seven permanent profiles.
Hundreds of curated skills.
Strict credential boundaries.
Isolated memory.
One command profile.
Disposable subagents.
Shared documentation.
Automated verification.
Recovery tooling.
A full production baseline.
And yeah, I named the whole thing after Wu-Tang Clan.
But this article isn’t really about the Wu-Tang theme.
That’s the fun part.
The real story is what the rebuild taught me about multi-agent systems in general.
Because here’s the truth:
More agents don’t automatically make your system better.
Most of the time, they just give you more places for shit to break.
## Most “Multi-Agent Systems” Are Just Fancy Group Chats
A lot of what gets called multi-agent today is basically roleplay with extra steps.
One model acts like a researcher.
Another acts like a coder.
Another acts like a critic.
They pass outputs back and forth.
Eventually somebody says the task is complete.
That can be useful.
But that’s not the same thing as running a real multi-agent system every day.
A real setup has to answer much harder questions.
Who owns each type of work?
Who has access to credentials?
Who’s allowed to talk to the outside world?
Who owns memory?
Who can publish?
Who can change infrastructure?
What happens when two agents both think a task belongs to them?
What happens when old documentation still routes work to an agent you deleted three weeks ago?
What happens after an update changes the runtime?
How do you know the live system is actually using the config you think it is?
That’s the difference.
A demo proves multiple agents can talk.
A real system proves they can work together without turning your machine into an AI clown car.
# There Are Really Three Different Kinds of Multi-Agent Setup
People tend to lump everything together under “multi-agent,” but there are a few very different ways to build one.
And choosing the wrong one is where a lot of the trouble starts.
## 1. Disposable Subagents
This is the easiest model.
You have one main agent.
That agent spins up temporary helpers for things like:
- research
- testing
- brainstorming
- verification
- critique
- edge-case hunting
Then those helpers disappear when the task is done.
This is perfect when the work is temporary.
Maybe one agent researches the docs.
Another checks for security problems.
Another reviews the plan and tries to tear it apart.
The parent agent gathers everything, makes the final call, and delivers the result.
Simple.
Clean.
No long-term baggage.
This is also where people make their first big mistake.
They turn every temporary role into a permanent agent.
Now the critic has its own memory.
Its own config.
Its own working directory.
Its own skills.
Its own scheduled tasks.
Its own little kingdom.
But why?
Sometimes a critic is just a prompt.
Not every useful role deserves permanent residency on your machine.
## 2. Permanent Specialist Profiles
A permanent profile makes sense when the role owns a real, durable lane of work.
That means it may need:
- its own memory
- its own working directory
- its own skill bundle
- its own project history
- different tools
- different boundaries
- recurring responsibilities
That’s how I built my current Hermes setup.
The permanent profiles are:
The names make the system easier for me to remember.
But the names aren’t the architecture.
The ownership is.
Each profile exists because it has a clear lane that comes up again and again.
That’s the bar.
Not “this would be a cool personality.”
Not “I might need this someday.”
Not “more agents looks impressive in a screenshot.”
A permanent profile should own something real.
## 3. Swarms
Then you’ve got swarms.
This is where multiple agents negotiate, vote, compete, debate, self-organize, or throw ideas into a giant digital food fight until something useful falls out.
Swarms can be great for:
- simulations
- broad research
- scientific exploration
- hypothesis generation
- adversarial testing
- search problems
- large sets of independent tasks
They’re also extremely easy to overbuild.
The problems show up fast:
- agents duplicate work
- nobody clearly owns the result
- costs become unpredictable
- routing changes from run to run
- context gets scattered
- internal chatter explodes
- agents start agreeing with each other without actually verifying anything
You can end up spending more compute on agents talking to agents than agents doing useful work.
For most personal systems, content workflows, software projects, and business operations, you probably don’t need a swarm.
You need a clear command structure and a handful of specialists that know their lanes.
# The Orchestrator Is the Most Important Agent in the System
Most people spend all their time designing specialist prompts
They obsess over the researcher.
The engineer.
The writer.
The reviewer.
But they barely think about the orchestrator.
That’s backwards.
The orchestrator is what determines whether your setup acts like a team or a pile of bots with name tags.
In my system, that role belongs to RZA.
RZA is responsible for:
- receiving the request
- figuring out what kind of work it is
- deciding whether to handle it directly or delegate it
- sending the right context
- collecting the results
- checking the evidence
- resolving conflicts
- enforcing approval gates
- delivering one final answer
That last part matters more than people realize.
A good orchestrator doesn’t dump five agent reports in your lap and call it a day.
That just makes you the project manager.
The specialist owns the lane.
The orchestrator owns the outcome.
That distinction is everything.
## Your Orchestrator Shouldn’t Secretly Be the Whole Company
There’s another problem I ran into.
You can create six specialist profiles, give them all clear jobs, document the routing, and still end up with a fake multi-agent system.
Why?
Because the main agent can already do everything.
It has every skill.
Every tool.
Every credential.
Every integration.
So instead of routing work, it just keeps doing everything itself.
Now you’ve got seven agents installed, but one giant monolith is still running the show.
That defeats the entire point.
RZA has explicit routing rules.
Deep research goes to GZA.
Normal coding goes to Masta Killa.
Official Hermes Agent contribution work goes to Inspectah Deck.
TRT editorial work goes to Ghostface.
X analytics and content strategy go to Method Man.
Windows runtime, gateways, cron, tunnels, and MCP work go to Raekwon.
RZA can still handle small tasks directly.
You don’t need to summon a committee because somebody asked you to rename a file.
But durable specialist work should go to the profile that owns it.
Otherwise you haven’t built a multi-agent system.
You’ve built a manager with six decorative employees.
# Giving Every Agent Every Skill Is a Terrible Idea
This one sounds smart at first.
Why not give every profile access to every skill?
Then nobody is ever missing anything.
Problem solved.
Except now every profile has a massive skill pool full of overlapping instructions, irrelevant workflows, duplicate tools, and conflicting guidance.
That creates:
- slower discovery
- bigger prompts
- worse routing
- more confusion
- harder audits
- more accidental tool use
- more maintenance
The better approach is curation.
Each specialist should have the skills that support its actual lane.
GZA gets research, source verification, competitive analysis, quantitative analysis, and evidence workflows.
Masta Killa gets debugging, testing, architecture, GitHub, releases, and engineering workflows.
Ghostface gets editorial research, drafting, SEO, WordPress, images, affiliate workflows, and publishing QA.
Method Man gets X analytics, post writing, claim verification, repurposing, experiments, and content strategy.
Raekwon gets Windows services, gateways, tunnels, cron, MCP, migration, recovery, and infrastructure tooling.
One of my audits originally reported giant skill counts for these profiles.
Later, we discovered those numbers were inflated.
The real skill sets were smaller.
And honestly?
That was better.
A skill count isn’t a capability score.
An agent with 150 vaguely related skills can be worse than one with 25 skills that actually belong there.
More isn’t always more.
Sometimes more is just a larger junk drawer.
# Credentials Should Stay at the Top
This was one of the biggest architectural decisions I made.
Only the command profile owns broad external access.
## In my setup:
- RZA owns Telegram
- RZA owns Discord
- RZA owns Composio
- specialists don’t inherit MCP servers
- specialists don’t store messaging credentials
- specialists don’t own public gateways
That means Ghostface can write an article.
Method Man can prepare an X post.
Raekwon can inspect the gateway.
But they can’t just publish, send, or connect to external services on their own.
Their work flows back to RZA.
RZA handles approval.
That’s how the privilege should move.
Work flows upward.
Credentials do not flow downward.
It adds a little friction.
That’s fine.
A little visible friction is better than invisible power spread across seven profiles.
## MCP Inheritance Can Quietly Blow Up Your Security Model
MCP is insanely powerful.
It’s also one of the fastest ways to create accidental privilege escalation.
One OAuth connection can expose multiple apps.
One MCP server can expose dozens of actions.
If every subagent inherits every MCP tool from the parent, one innocent delegation can suddenly give a temporary helper access to Gmail, WordPress, Cloudflare, GitHub, analytics, or whatever else you’ve connected.
That’s not a small detail.
That’s your security model.
## In my system:
```
delegation.inherit_mcp_toolsets = false
```
Subagents don’t automatically inherit integrations.
Permanent specialists don’t carry Composio config.
RZA remains the controlled gateway.
Sometimes that means a specialist identifies an action it can’t perform directly.
Good.
That creates a clear handoff.
The system has to ask the profile with the authority to do it.
That’s not a limitation.
That’s the boundary working.
## Memory Should Be Isolated, but Truth Should Be Shared
A research agent shouldn’t absorb all the habits of a social media writer.
An infrastructure profile shouldn’t carry editorial assumptions.
A coding profile working on one repo shouldn’t randomly remember project rules from another.
Permanent profiles need isolated memory.
That keeps them focused.
But isolated memory creates another problem.
How does everyone stay aligned?
You can’t rely on every agent remembering everything.
That gets messy fast.
My answer was Nexus.
Nexus is the durable shared knowledge layer.
It contains:
- role definitions
- routing rules
- project state
- decisions
- handoffs
- operating procedures
- baselines
- recovery instructions
- historical records
- ownership metadata
Memory stays local.
> **Tony Simons@tonysimons_**: [原文链接](https://x.com/tonysimons_/status/2052013536851694069)
>
Nexus holds the shared truth.
That gives each agent a focused identity without turning the system into seven isolated brains that never agree on what’s happening.
## Documentation Isn’t Just Documentation Anymore
This was one of the biggest surprises in the audit.
The live profiles were mostly correct.
The docs weren’t.
Old Nexus pages still referenced retired profiles.
Some editorial work was still routed through the default profile.
Other pages pointed to profile IDs that no longer existed.
That’s not harmless.
Agents read documentation.
If the docs say a retired agent owns something, the system may still try to route work there.
In an agentic setup, documentation is part of the runtime.
A profile rename isn’t done when you change the folder name.
You also need to check:
- configuration
- routing
- skills
- credentials
- scheduled tasks
- memory
- ownership metadata
- docs
- historical references
We kept the old names where they were historically accurate.
But active control documents were updated to use the live Wu-Tang architecture.
History can mention ghosts.
Your routing layer can’t send them work.
## The Boring Infrastructure Is Usually Where Things Break
Everybody wants to talk about models, prompts, agents, and reasoning.
Meanwhile, the actual system is held together by:
- scheduled tasks
- PowerShell scripts
- background daemons
- ports
- process trees
- lock files
- environment variables
- startup wrappers
- working directories
One of the issues we found involved the computer-use driver.
Two versions were installed:
0.11.0
0.12.3
The scheduled task was still pointing directly at the old 0.11.0 binary.
So the new version was installed.
But Windows kept launching the old one.
That’s the kind of bug that can survive a dozen surface-level health checks.
The fix was a wrapper script.
Now the scheduled task launches:
```
C:\Users\asimo\.cua-driver\start-cua-driver.ps1
```
The wrapper automatically selects the newest installed release.
So future upgrades don’t require manually editing the scheduled task every time.
That’s not glamorous.
It is, however, the difference between “updated” and actually updated.
# Never Trust One Green Status Light
This came up more than once.
A status field can be stale.
A process can be alive but useless.
A port can be open because the wrong service owns it.
A task can report success while launching an outdated binary.
A config file can look perfect while the live process loaded something else.
At one point, the Hermes gateway status said Telegram and Discord were disconnected.
The live logs showed both connected.
The gateway was running.
The channel directory was populated.
There was only one authoritative process.
The status flags were stale.
The opposite can happen too.
A dashboard can show green while the runtime is quietly broken underneath it.
That’s why a real audit has to check multiple layers:
1. Config
2. Process
3. Command line
4. Logs
5. Network behavior
6. Real capability
7. Cleanup after the test
An open port doesn’t prove your system works.
Neither does an HTTP 200.
Neither does a process ID.
You have to test the thing.
## A Real Audit Tests Behavior, Not Just Files
The final audit didn’t stop at checking directories and YAML.
It ran the system.
We verified:
- real inference across all seven profiles
- representative skill loading
- browser launch
- CDP connection
- DOM access
- screenshots
- navigation
- clean shutdown
- gateway process uniqueness
- Telegram
- Discord
- Composio isolation
- cron ownership
- scheduled tasks
- CUA runtime
- dependency security
- Nexus routing
- Git state
- rollback paths
That’s the standard.
A profile isn’t healthy because its folder exists.
A skill isn’t installed because there’s a SKILL.md.
A gateway isn’t working because there’s a PID.
A recovery plan isn’t real because somebody wrote “restore from backup.”
Everything important needs to be executable.
## The Audit Found Problems With the Audit
This part was almost funny.
The first certification came back basically saying everything was perfect.
Then we audited the certification itself.
And found problems.
The dependency report was wrong
The first report said pynacl wasn’t installed.
It was installed.
It still had two known vulnerabilities.
The actual exploit path was limited to voice-related functionality, so it remained a low accepted risk.
But the claim was wrong.
The skill counts were inflated
The reported skill counts were much larger than the actual curated sets.
The system was still healthy.
The smaller skill sets were actually more focused.
But the certification evidence was inaccurate.
The remediation branch wasn’t merged
Several important changes were sitting on a feature branch:
- pyproject.toml
- uv.lock
- gateway/run.py
The live system worked.
But the Git baseline wasn’t as clean as the certification made it sound.
None of those issues destroyed the architecture.
But they proved something important.
A system audit should survive an audit of the audit.
A green check that can’t be independently reproduced isn’t a green check.
It’s decoration.
## Production Ready Means Recoverable
Once the system passed the second review, we froze a production baseline.
That baseline includes:
- a full snapshot
- profile inventory
- model and provider settings
- skill counts
- skill hashes
- task definitions
- cron definitions
- gateway command line
- operator policy
- repo commits
- important file hashes
- CUA version
- dependency lock hash
- accepted risks
- a verification script
- a recovery runbook
- a Nexus baseline page
Because “it works right now” isn’t enough.
The real question is:
Can I rebuild this if something breaks?
Can a fresh Hermes session restore it without needing six months of chat history?
Can I verify drift after an update?
Can I prove what changed?
That’s what turns an agent setup into infrastructure.
# The Multi-Agent Architecture I’d Recommend
For most serious personal setups or small teams, I’d keep it simple.
One command profile
This profile owns:
- user interaction
- routing
- approvals
- final synthesis
- public tools
- high-risk credentials
A small number of permanent specialists
Each specialist gets:
- one durable lane
- one clear identity
- its own memory
- its own working directory
- a curated skill set
- strict boundaries
- no unnecessary credentials
Disposable subagents
Use them for temporary work:
- research
- testing
- critique
- brainstorming
- adversarial review
- parallel analysis
One shared knowledge layer
Use it for:
- project state
- decisions
- ownership
- handoffs
- routing rules
- procedures
- history
- recovery
One verification layer
Continuously check for:
- model drift
- missing skills
- credential leakage
- duplicate gateways
- stale scheduled tasks
- retired profile references
- broken routing
- Git drift
- baseline changes
That gives you specialization without building an autonomous government inside your laptop.
## Before You Create Another Agent, Ask Yourself This
Does this role own real, recurring work?
Does it need separate memory?
Does it need a different working directory?
Does it need different permissions?
Does it need a different skill set?
Will I know exactly when work should route to it?
Will I know exactly when work should not route to it?
Does it reduce confusion?
Or am I just creating another character because multi-agent sounds cool?
Could this be a disposable subagent instead?
If you can’t answer those questions, you probably don’t need another permanent agent.
You need a better workflow.
## The Real Point
The goal of a multi-agent system isn’t to recreate a company.
It isn’t to fill a dashboard with avatars.
It isn’t to make agents hold meetings with other agents while you watch the token meter spin.
The goal is to divide work into clear lanes.
Protect credentials.
Preserve context.
Reduce cognitive load.
Make ownership obvious.
Keep the system recoverable.
And get better results without forcing you to babysit the whole operation.
My setup happens to use RZA, GZA, Masta Killa, Inspectah Deck, Ghostface Killah, Method Man, and Raekwon.
That part is fun.
But underneath it is a serious architecture:
- one command surface
- permanent specialist ownership
- disposable subagents
- isolated memory
- curated skills
- centralized credentials
- explicit approval gates
- shared durable knowledge
- repeatable verification
- documented recovery
That’s what makes it work.
Not the theme.
Not the agent count.
Not the screenshots.
The architecture.
More agents aren’t the upgrade.
Clearer ownership is.
## 相关链接
- [Tony Simons](https://x.com/tonysimons_)
- [@tonysimons_](https://x.com/tonysimons_)
- [13K](https://x.com/tonysimons_/status/2081054380241879425/analytics)
- [May 6](https://x.com/tonysimons_/status/2052013536851694069)
- [8.8K](https://x.com/tonysimons_/status/2052013536851694069/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:30 AM · Jul 26, 2026](https://x.com/tonysimons_/status/2081054380241879425)
- [13.6K Views](https://x.com/tonysimons_/status/2081054380241879425/analytics)
- [View quotes](https://x.com/tonysimons_/status/2081054380241879425/quotes)
---
*导出时间: 2026/7/26 11:45:21*
---
## 中文翻译
# Wu-Tang Forever：我的 Hermes 多智能体设置绝非儿戏
**作者**：Tony Simons
**日期**：2026-05-06T13:12:06.000Z
**来源**：[https://x.com/tonysimons_/status/2081054380241879425](https://x.com/tonysimons_/status/2081054380241879425)
---
现在每个人都想要一个多智能体设置。
一个研究员。
一个程序员。
一个作家。
一个审核员。
一个浏览器智能体。
一个项目经理。
也许还有几个子智能体四处游荡，以备不时之需。
听起来威力无穷，直到你真正尝试运行它。
然后你会意识到，你基本上建立了一个 AI 办公室，那里每个人都有同样的钥匙，没人知道谁拥有任务，三个智能体在操作同一个文件，而“经理”反正还在做着所有的工作。
我刚刚围绕一个适当的多配置文件架构，彻底重建了我整个 Hermes Agent 设置。
七个永久配置文件。
数百个精选技能。
严格的凭证边界。
隔离的内存。
一个命令配置文件。
一次性子智能体。
共享文档。
自动验证。
恢复工具。
一个完整的生产基线。
是的，我用 Wu-Tang Clan（武当派）的名字命名了整个东西。
但这篇文章其实并不是关于 Wu-Tang 主题的。
那是有趣的部分。
真正的故事是这次重建教会了我关于多智能体系统的哪些普遍道理。
因为事实是这样的：
更多的智能体并不会自动让你的系统变得更好。
大多数时候，它们只是给你提供了更多出问题的环节。
## 大多数“多智能体系统”只是花哨的群聊
如今很多被称为多智能体的东西，基本上就是多了几步的角色扮演。
一个模型表现得像个研究员。
另一个表现得像个程序员。
另一个表现得像个评论家。
它们来回传递输出。
最终有人说任务完成了。
这可能很有用。
但这和每天都在运行一个真正的多智能体系统不是一回事。
一个真正的设置必须回答更难的问题。
谁拥有每种类型的工作？
谁有权访问凭证？
谁被允许与外部世界对话？
谁拥有内存？
谁可以发布？
谁可以更改基础设施？
当两个智能体都认为任务属于自己时会发生什么？
当旧文档仍然将工作路由到你三周前删除的智能体时会发生什么？
当更新改变了运行时之后会发生什么？
你怎么知道正在运行的系统实际上正在使用你认为的配置？
这就是区别。
演示证明了多个智能体可以对话。
真正的系统证明了它们可以协同工作，而不会把你的机器变成一个 AI 小丑车。
# 实际上有三种不同的多智能体设置
人们倾向于把所有东西都归在“多智能体”名下，但有几种非常不同的构建方式。
而选择了错误的方式，正是许多麻烦开始的地方。
## 1. 一次性子智能体
这是最简单的模式。
你有一个主智能体。
该智能体为以下事项启动临时助手：
- 研究
- 测试
- 头脑风暴
- 验证
- 评论
- 边缘情况搜寻
然后这些助手在任务完成后消失。
当工作是暂时的时候，这非常完美。
也许一个智能体研究文档。
另一个检查安全问题。
另一个审查计划并试图将其拆解。
父智能体收集所有信息，做出最终决定，并交付结果。
简单。
干净。
没有长期的包袱。
这也是人们犯下第一个大错误的地方。
他们将每个临时角色变成了永久智能体。
现在评论家有了自己的内存。
自己的配置。
自己的工作目录。
自己的技能。
自己的计划任务。
自己的小王国。
但是为什么？
有时评论家只是一个提示词。
并不是每个有用的角色都值得在你的机器上获得永久居留权。
## 2. 永久专家配置文件
当该角色拥有一个真正的、持久的工作领域时，永久配置文件才有意义。
这意味着它可能需要：
- 自己的内存
- 自己的工作目录
- 自己的技能包
- 自己的项目历史
- 不同的工具
- 不同的边界
- 循环职责
我就是这样构建当前的 Hermes 设置的。
永久配置文件是：
这些名字让系统更容易记住。
但名字不是架构。
所有权才是。
每个配置文件的存在都是因为它有一条清晰且反复出现的工作领域。
这就是标准。
不是“这会是一个很酷的个性”。
不是“我有一天可能会用到这个”。
不是“更多的智能体在截图中看起来令人印象深刻”。
永久配置文件应该拥有某种真实的东西。
## 3. 群体
然后你有群体。
这是多个智能体协商、投票、竞争、辩论、自我组织，或者把想法扔进一个巨大的数字混战中，直到有用的东西掉出来的地方。
群体可能非常适合：
- 仿真
- 广泛的研究
- 科学探索
- 假设生成
- 对抗性测试
- 搜索问题
- 大量的独立任务
它们也非常容易过度构建。
问题很快就会显现：
- 智能体重复工作
- 没有人清楚地拥有结果
- 成本变得不可预测
- 路由在运行之间发生变化
- 上下文变得分散
- 内部闲聊爆炸
- 智能体开始在没有实际验证任何事情的情况下相互同意
你最终可能会在智能体与智能体对话上花费更多的算力，而不是在智能体做有用的工作上。
对于大多数个人系统、内容工作流、软件项目和业务运营，你可能不需要一个群体。
你需要一个清晰的指挥结构和少数几个清楚自己领域的专家。
# 编排器是系统中最重要的智能体
大多数人把所有时间都花在设计专家提示词上
他们痴迷于研究员。
工程师。
作家。
审核员。
但他们几乎不考虑编排器。
这是本末倒置。
编排器决定了你的设置是像一个团队，还是像一堆带着名牌的机器人。
在我的系统中，这个角色属于 RZA。
RZA 负责：
- 接收请求
- 弄清楚它是什么类型的工作
- 决定是直接处理还是委派
- 发送正确的上下文
- 收集结果
- 检查证据
- 解决冲突
- 执行批准关卡
- 交付一个最终答案
最后一部分比人们意识到的更重要。
一个好的编排器不会把五个智能体报告扔在你怀里就算完事了。
那只是让你变成了项目经理。
专家拥有领域。
编排器拥有结果。
这种区别就是一切。
## 你的编排器不应该秘密地是整个公司
我遇到的另一个问题。
你可以创建六个专家配置文件，给它们所有明确的工作，记录路由，最后还是会得到一个假的多智能体系统。
为什么？
因为主智能体已经可以做所有事情了。
它拥有所有技能。
所有工具。
所有凭证。
所有集成。
所以它没有路由工作，而是一直自己做所有事情。
现在你安装了七个智能体，但一个巨大的单体仍然在掌管一切。
这完全违背了初衷。
RZA 有明确的路由规则。
深度研究交给 GZA。
普通编码交给 Masta Killa。
官方 Hermes Agent 贡献工作交给 Inspectah Deck。
TRT 编辑工作交给 Ghostface。
X（推特）分析和内容策略交给 Method Man。
Windows 运行时、网关、cron、隧道和 MCP 工作交给 Raekwon。
RZA 仍然可以直接处理小任务。
你不需要召集委员会，仅仅因为有人让你重命名一个文件。
但持久的专家工作应该交给拥有它的配置文件。
否则你没有建立一个多智能体系统。
你建立了一个经理和六个装饰性员工。
# 给每个智能体每个技能是一个糟糕的主意
这个想法起初听起来很聪明。
为什么不给每个配置文件访问每个技能的权限？
这样就没有人会错过任何东西。
问题解决了。
除了现在每个配置文件都有一个巨大的技能池，里面充满了重叠的指令、不相关的工作流、重复的工具和冲突的指导。
这会导致：
- 发现变慢
- 提示词变大
- 路由变差
- 更多困惑
- 更难审计
- 更多意外的工具使用
- 更多维护
更好的方法是策划。
每个专家应该拥有支持其实际领域的技能。
GZA 获得研究、来源验证、竞争分析、定量分析和证据工作流。
Masta Killa 获得调试、测试、架构、GitHub、发布和工程工作流。
Ghostface 获得编辑研究、起草、SEO、WordPress、图片、联盟工作流和发布 QA。
Method Man 获得 X 分析、帖子写作、声明验证、再利用、实验和内容策略。
Raekwon 获得 Windows 服务、网关、隧道、cron、MCP、迁移、恢复和基础设施工具。
我的一次审计最初报告了这些配置文件的巨大技能数量。
后来，我们发现这些数字被夸大了。
真正的技能集更小。
老实说？
那更好。
技能数量不是能力分数。
一个拥有 150 个模糊相关技能的智能体可能比一个拥有 25 个实际属于那里的技能的智能体更差。
更多并不总是更多。
有时更多只是一个更大的杂物抽屉。
## 凭证应该留在顶层
这是我做出的最大的架构决策之一。
只有命令配置文件拥有广泛的外部访问权限。
## 在我的设置中：
- RZA 拥有 Telegram
- RZA 拥有 Discord
- RZA 拥有 Composio
- 专家不继承 MCP 服务器
- 专家不存储消息凭证
- 专家不拥有公共网关
这意味着 Ghostface 可以写一篇文章。
Method Man 可以准备一条 X 帖子。
Raekwon 可以检查网关。
但他们不能自己发布、发送或连接到外部服务。
他们的工作流回到 RZA。
RZA 处理批准。
这就是特权应该移动的方式。
工作向上流动。
凭证不向下流动。
这增加了一点摩擦。
这没关系。
一点可见的摩擦比分布在七个配置文件中的不可见权力要好。
## MCP 继承可以悄悄破坏你的安全模型
MCP 强大得惊人。
它也是创建意外权限升级的最快方式之一。
一个 OAuth 连接可以暴露多个应用程序。
一个 MCP 服务器可以暴露几十个操作。
如果每个子智能体都从父智能体继承每个 MCP 工具，一个无辜的委派可能会突然给一个临时助手访问 Gmail、WordPress、Cloudflare、GitHub、分析或你连接的任何其他东西的权限。
这不是一个小细节。
这是你的安全模型。
## 在我的系统中：
```
delegation.inherit_mcp_toolsets = false
```
子智能体不会自动继承集成。
永久专家不携带 Composio 配置。
RZA 保持受控网关。
有时这意味着专家识别出它无法直接执行的操作。
很好。
这创建了一个清晰的交接。
系统必须询问有权执行此操作的配置文件。
这不是限制。
这是边界在起作用。
## 内存应该隔离，但真相应该共享
研究智能体不应该吸收社交媒体作家的所有习惯。
基础设施配置文件不应该携带编辑假设。
在一个仓库上工作的编码配置文件不应该随机记住另一个仓库的项目规则。
永久配置文件需要隔离的内存。
这使它们保持专注。
但隔离的内存会产生另一个问题。
每个人如何保持一致？
你不能依赖每个智能体记住所有事情。
那很快就会变得混乱。
我的答案是 Nexus。
Nexus 是持久的共享知识层。
它包含：
- 角色定义
- 路由规则
- 项目状态
- 决策
- 交接
- 操作程序
- 基线
- 恢复说明
- 历史记录
- 所有权元数据
内存保持本地。
> **Tony Simons@tonysimons_**: [原文链接](https://x.com/tonysimons_/status/2052013536851694069)
>
Nexus 保存共享真相。
这给每个智能体一个专注的身份，而不会将系统变成七个从未就正在发生的事情达成一致的孤立大脑。
## 文档不再只是文档
这是审计中最大的惊喜之一。
实时配置文件大多是正确的。
文档不是。
旧的 Nexus 页面仍然引用已退休的配置文件。
一些编辑工作仍然通过默认配置文件路由。
其他页面指向不再存在的配置文件 ID。
这并非无害。
智能体阅读文档。
如果文档说退休的智能体拥有某样东西，系统可能仍然尝试将工作路由到那里。
在智能体设置中，文档是运行时的一部分。
重命名配置文件不仅仅是更改文件夹名称。
你还需要检查：
- 配置
- 路由
- 技能
- 凭证
- 计划任务
- 内存
- 所有权元数据
- 文档
- 历史引用
我们在历史上准确的地方保留了旧名称。
但活动控制文档已更新以使用实时 Wu-Tang 架构。
历史可以提到幽灵。
你的路由层不能给他们工作。
## 无聊的基础设施通常是事情崩溃的地方
每个人都想谈论模型、提示词、智能体和推理。
与此同时，实际的系统由以下内容维系：
- 计划任务
- PowerShell 脚本
- 后台守护进程
- 端口
- 进程树
- 锁文件
- 环境变量
- 启动包装器
- 工作目录
我们发现的问题之一涉及计算机使用驱动程序。
安装了两个版本：
0.11.0
0.12.3
计划任务仍然直接指向旧的 0.11.0 二进制文件。
所以安装了新版本。
但 Windows 一直启动旧的。
这是可以在十几次表面级健康检查中幸存下来的那种错误。
修复方法是一个包装脚本。
现在计划任务启动：
```
C:\Users\asimo\.cua-driver\start-cua-driver.ps1
```
包装器自动选择最新安装的版本。
因此未来的升级不需要每次都手动编辑计划任务。
这不光鲜。
然而，这是“已更新”和实际更新之间的区别。
# 永远不要相信一个绿色状态灯
这种情况不止一次出现。
状态字段可能过时。
进程可能活着但没用。
端口可能打开是因为错误的服务拥有它。
任务可能报告成功，同时启动过时的二进制文件。
配置文件可能看起来完美，而实时进程加载了其他东西。
有一次，Hermes 网关状态显示 Telegram 和 Discord 已断开连接。
实时日志显示两者都已连接。
网关正在运行。
通道目录已填充。
只有一个权威进程。
状态标志已过时。
相反的情况也可能发生。
仪表板可能显示绿色，而运行时在下面悄无声息地坏了。
这就是真正的审计必须检查多个层的原因：
1. 配置
2. 进程
3. 命令行
4. 日志
5. 网络行为
6. 实际能力
7. 测试后清理
打开的端口不能证明你的系统工作。
HTTP 200 也不能。
进程 ID 也不能。
你必须测试这个东西。
## 真正的审计测试行为，而不仅仅是文件
最终审计不仅限于检查目录和 YAML。
它运行了系统。
我们验证了：
- 所有七个配置文件的实际推理
- 代表性技能加载
- 浏览器启动
- CDP 连接
- DOM 访问
- 截图
- 导航
- 干净关机
- 网关进程唯一性
- Telegram
- Discord
- Composio 隔离
- cron 所有权
- 计划任务
- CUA 运行时
- 依赖安全性
- Nexus 路由
- Git 状态
- 回滚路径
这就是标准。
配置文件不是健康仅仅因为它的文件夹存在。
技能不是安装仅仅因为有 SKILL.md。
网关不是工作仅仅因为有 PID。
恢复计划不是真实仅仅因为有人写了“从备份恢复”。
所有重要的东西都需要可执行。
## 审计发现了审计的问题
这部分几乎很有趣。
第一次认证基本上说一切都很完美。
然后我们审计了认证本身。
发现了问题。
依赖报告是错的
第一份报告说 pynacl 没有安装。
它安装了。
它仍然有两个已知漏洞。
实际利用路径仅限于语音相关功能，因此它仍然是一个低接受风险。
但声明是错的。
技能数字被夸大了
报告的技能数量远大于实际策划的集合。
系统仍然健康。
较小的技能集实际上更专注。
但认证证据不准确。
修复分支没有合并
几个重要的更改停留在功能分支上：
- pyproject.toml
- uv.lock
- gateway/run.py
实时系统工作。
但 Git 基线不像认证听起来那么干净。
这些问题都没有破坏架构。
但它们证明了一些重要的东西。
系统审计应该经得起对审计的审计。
一个无法独立复制的绿色检查不是绿色检查。
它是装饰。
## 生产就绪意味着可恢复
一旦系统通过了第二次审查，我们冻结了生产基线。
该基线包括：
- 完整快照
- 配置文件清单
- 模型和提供商设置
- 技能计数
- 技能哈希
- 任务定义
- cron 定义
- 网关命令行
- 操作员策略
- 仓库提交
- 重要文件哈希
- CUA 版本
- 依赖锁哈希
- 接受的风险
- 验证脚本
- 恢复运行手册
- Nexus 基线页面
因为“它现在工作”是不够的。
真正的问题是：
如果出问题了我能重建这个吗？
一个新的 Hermes 会话可以在不需要六个月聊天历史的情况下恢复它吗？
我可以在更新后验证漂移吗？
我能证明什么改变了吗？
这就是将智能体设置变成基础设施的东西。
# 我会推荐的多智能体架构
对于大多数严肃的个人设置或小团队，我会保持简单。
一个命令配置文件
此配置文件拥有：
- 用户交互
- 路由
- 批准
- 最终综合
- 公共工具
- 高风险凭证
少数永久专家
每个专家获得：
- 一个持久领域
- 一个清晰的身份
- 自己的内存
- 自己的工作目录
- 策划的技能集
- 严格的边界
- 没有不必要的凭证
一次性子智能体
将它们用于临时工作：
- 研究
- 测试
- 评论
- 头脑风暴
- 对抗性审查
- 并行分析
一个共享知识层
将其用于：
- 项目状态
- 决策
- 所有权
- 交接
- 路由规则
- 程序
- 历史
- 恢复
一个验证层
持续检查：
- 模型漂移
- 缺失技能
- 凭证泄漏
- 重复网关
- 过时的计划任务
- 退休的配置文件引用
- 损坏的路由
- Git 漂移
- 基线更改
这给你专业化，而不会在你的笔记本电脑里建立一个自治政府。
## 在你创建另一个智能体之前，问问你自己
这个角色拥有真实的、循环的工作吗？
它需要单独的内存吗？
它需要不同的工作目录吗？
它需要不同的权限吗？
它需要不同的技能集吗？
我会确切地知道何时工作应该路由到它吗？
我会确切地知道何时工作不应该路由到它吗？
它减少困惑吗？
还是我只是因为多智能体听起来很酷而创建另一个角色？
这可以是一次性子智能体吗？
如果你不能回答那些问题，你可能不需要另一个永久智能体。
你需要更好的工作流。
## 真正的重点
多智能体系统的目标不是重建一个公司。
它不是用头像填满仪表板。
它不是让智能体与其他智能体举行会议，而你看着令牌表旋转。
目标是将工作划分为清晰的领域。
保护凭证。
保留上下文。
减少认知负荷。
使所有权显而易见。
保持系统可恢复。
并在无需你保姆式管理整个操作的情况下获得更好的结果。
我的设置恰好使用 RZA、GZA、Masta Killa、Inspectah Deck、Ghostface Killah、Method Man 和 Raekwon。
那部分很有趣。
但在下面是一个严肃的架构：
- 一个命令表面
- 永久专家所有权
- 一次性子智能体
- 隔离的内存
- 策划的技能
- 集中凭证
- 明确的批准关卡
- 共享的持久知识
- 可重复的验证
- 记录在案的恢复
这就是它起作用的原因。
不是主题。
不是智能体数量。
不是截图。
架构。
更多的智能体不是升级。
更清晰的所有权才是升级。