关于 AgentZ

这是我做的第二个完整的 Agent。

上一个 Agent 面向比较具体的业务场景，所有工具基本都是调用后端函数，重点是把固定的事情稳定完成，并没有特别追求通用性。AgentZ 的方向不太一样，我们希望它能够处理更多类型的任务，所以需要让它拥有一个可以执行命令、操作文件的运行环境。

我们当时觉得，Agent 似乎更适合在 Linux 环境里工作。很多开发工具和命令本来就是围绕 Linux 设计的，而且一个独立的 Linux 环境可以让权限边界更清楚，也能尽量把任务执行过程和主机隔离开。这样即使 Agent 执行任务时出现问题，影响也会尽量限制在 Worker 的运行环境里。

其实做 AgentZ 的时候中间有过不少想法，只是当时没有及时记下来。现在回头看，很多细节已经想不起来了，只能先把还记得的部分写下来，orz。

关于 AgentZ 的架构，可以简单分成三个部分：桌面端、Server 和 Worker。桌面端负责和用户交互，Server 运行在主机上，负责调用大模型、管理会话和协调任务，Worker 则负责实际执行命令和文件操作。

这里比较重要的设计，就是把 Server 和 Worker 分开。Worker 既是执行进程，也是 Agent 运行任务时使用的环境。把它放到独立的 Linux 环境里后，权限模型更清楚，执行环境也和主机隔离开了。

如果不拆出 Worker，所有功能都放在 Server 里当然也能做，但模型调用、会话管理、工具执行和运行时管理容易慢慢纠缠在一起。以后增加功能时，可能很难判断应该改哪里，也更容易因为一个改动影响其他部分。现在经常会让 AI 帮忙写代码，项目本身的维护成本也需要考虑，尽量让各部分职责清楚一些还是有必要的。

另外，Worker 独立出来后，也更方便处理异常情况。命令卡住、输出过长、子进程没有退出，这些问题可以尽量在 Worker 内部处理。Worker 出现问题时，也不至于直接影响整个 Server。

当然，仔细设计的话，所有东西都放在 Server 里也不是完全不行。但人总会有没考虑到的地方，分开之后可以减少一些维护和判断成本。

Server 和 Worker 之间通过 MCP 通信。如果要问我为什么用 MCP，我的答案其实很简单：Worker 本身就是一系列可以被 Agent 调用的工具，而 MCP 正好适合描述和调用这类工具，所以用起来比较合适。

说到这里又想到一点，把 Worker 独立出来之后，后续做远程 Worker 会简单很多。只要通信方式和工具接口保持一致，就可以把 Worker 搬到另一台 Linux 机器上，Server 不需要大改，代码也只需要维护一套，耶耶耶。

这篇先简单记录我对 AgentZ 的理解。后面如果还记得更多细节，再继续写它的运行环境和具体任务执行过程。