Agent 和 Console 的关系

Downcity 里有两个经常同时出现的概念：

• agent：单个项目的运行时
• town / Console：全局控制面

一句话区分

• agent 管“这个项目怎么运行”
• town 管“有哪些项目、本地共享 chat accounts 和入口”

如果你习惯把系统拆成“控制面”和“执行面”，也可以这样记：

• town / Console 是控制面
• agent 是执行面

Console 负责的事情

Console 或 city 级运行时主要负责：

• 管理多个 agent 项目
• 查看 City 连接与 Agent 执行绑定
• 维护本地共享 chat account
• 提供控制面 API
• 为 UI 提供聚合视图

这些能力天然更适合做成全局资源，因为它们通常不会只服务于单个项目。

Agent 负责的事情

单个 agent 运行时主要负责：

• 读取当前项目配置
• 创建会话并执行对话
• 启动项目 plugin
• 绑定项目使用的模型
• 对外暴露项目级 HTTP / CLI 入口
• 落盘当前项目的消息和日志

这些能力则和具体项目高度绑定，因为它们受项目提示词、项目配置和项目历史数据直接影响。

为什么要这样分

如果不把两者拆开，系统会很快混乱：

• 多项目治理和单项目执行会耦合在一起
• 项目配置和全局配置边界会不清楚
• 一个项目出问题时不容易定位是控制面问题还是运行时问题

从代码层面看，很多 CLI 和 HTTP 操作之所以能保持语义清楚，就是因为它们先在 city 侧定位“目标 agent 项目”，然后再把执行交给对应的 agent runtime。

对用户有什么影响

你在日常使用时只需要记住两件事：

1. 配置项目本身时，改的是项目里的文件，例如 downcity.json
2. 管理本地共享资源时，使用的是 Town 能力，例如 chat account、Console

常见例子

绑定模型

• 模型本身在 City AIService 目录里
• 当前项目使用哪个模型，由项目的 downcity.json.execution.modelId 决定

所以“模型定义”和“模型选择”是两层东西：

• 模型定义在 City 层
• 模型选择在项目层

绑定聊天渠道

• bot 凭据和 chat account 是 Town 级共享资源
• 当前 agent 只是在项目配置里绑定 channelAccountId

因此，项目配置中出现的通常是：

{
  "channelAccountId": "telegram-main"
}

而不是 bot token 本身。

查看状态

• 看某个项目是否运行，用 town agent status
• 看全局有哪些 agent，用 town agent list

一个高频误区

很多人会问：“既然我用的也是 town agent ... 命令，那为什么还要强调 agent 是独立运行时？”

答案是：

• town agent ... 只是用户入口
• 真正被启动、被管理、被执行的是单项目 agent runtime

也就是说，命令入口属于 city，执行实体属于 agent。

继续阅读

• Agent 项目结构
• 执行模型