Codeg：企业级多智能体编码工作台，统一管理AI编程助手与远程协作-编程实验室

1. 项目概述：一个企业级的多智能体编码工作台

如果你和我一样，每天都要和好几个AI编程助手打交道——Claude Code在终端里跑着，Codex CLI在另一个窗口，偶尔还要切到OpenCode或者Gemini CLI去处理点别的任务——那你肯定也头疼过。每个工具都有自己的会话文件、不同的配置路径、独立的操作界面，信息散落各处，切换起来费时费力。更别提想把这些AI助手和你的即时通讯工具（比如Telegram、飞书）打通，实现远程任务下发和实时通知了。这种割裂的体验，让我一直想找一个能“一统江湖”的解决方案。

直到我遇到了Codeg。它不是一个全新的AI编程工具，而是一个企业级的、多智能体编码工作台。你可以把它理解为一个“指挥中心”或者“集成面板”。它的核心价值在于，把市面上主流的本地AI编码智能体（Agent）——包括Claude Code、Codex CLI、OpenCode、Gemini CLI、OpenClaw、Cline等等——全部整合到一个统一的界面里。这个界面可以是桌面应用，也可以是一个独立的Web服务器，甚至是一个Docker容器。这意味着，你可以在本地用桌面版高效工作，也可以把服务器部署在远程，然后从任何一台电脑的浏览器访问，实现真正的远程开发。

Codeg解决的痛点非常明确：统一管理、集中对话、并行开发、远程协作。它通过解析各个智能体本地存储的会话文件，把所有对话历史聚合到一个结构化的视图中。它内置了基于git worktree的并行开发流程，让你可以同时开展多个功能分支而互不干扰。最让我惊喜的是它的“聊天频道”功能，你可以把Telegram、飞书（Lark）、微信（iLink）等通讯工具直接连接到你的AI智能体上，在聊天软件里就能创建任务、发送指令、审批权限、查看实时进度，完全不用打开Codeg的界面。对于需要频繁沟通或者远程协作的团队来说，这个功能简直是生产力神器。

无论你是一个追求极致效率的独立开发者，还是一个需要管理多个AI助手和项目团队的Tech Lead，Codeg都值得你花时间深入了解。它用一套优雅的技术栈（Next.js + Tauri + Rust）构建，既保证了现代Web应用的交互体验，又通过Rust核心获得了本地操作的性能和安全性。接下来，我就带你从里到外，彻底拆解这个项目，看看它是如何实现的，以及我们如何能最大化地利用它。

2. 核心架构与设计思路拆解

要理解Codeg为什么强大，得先看明白它的架构设计。这不是一个简单的“外壳”应用，而是一个深思熟虑的、分层清晰的系统。

2.1 技术栈选型：为什么是Next.js + Tauri + Rust？

Codeg选择了前端用Next.js 16（静态导出），桌面层用Tauri 2，核心业务逻辑用Rust来实现。这个组合非常有意思，每一层都承担了明确的职责，并且做出了最优解。

前端 (Next.js 16 + React 19):

为什么是Next.js？首先，Codeg需要的是一个复杂、交互丰富的单页面应用（SPA），用来展示聚合的对话、文件树、Git状态、终端等。Next.js提供了最成熟、开箱即用的React框架体验，其App Router和Server Components模式（虽然这里是静态导出）能很好地组织复杂UI。更重要的是，Next.js的“静态导出”（output: "export"）功能，允许将整个应用预构建为纯静态文件（HTML, JS, CSS）。这对于Codeg的两种形态至关重要：桌面版可以将这些静态文件打包进Tauri；服务器版则可以直接由Rust HTTP服务器托管，无需Node.js运行时，部署极其轻量。
约束与应对：使用静态导出意味着不能使用Next.js的动态路由（如[slug]）。Codeg的应对策略是改用URL查询参数（query params）来实现页面状态的管理。同时，整个前端必须运行在严格的TypeScript模式下，保证类型安全，这对于一个要与多种本地文件格式和Rust后端通信的项目来说，是减少运行时错误的关键。

桌面层 (Tauri 2):

为什么是Tauri，而不是Electron？这是性能和安全性的双重选择。Tauri使用系统的WebView（在Linux/macOS上是WebKitGTK，在Windows上是WebView2）来渲染前端，而不是像Electron那样打包一个完整的Chromium。这带来的直接好处是应用体积大幅减小（从几百MB降到几十MB），内存占用显著降低，并且启动更快。对于Codeg这种需要常驻后台、同时处理文件I/O和网络请求的工具，轻量化至关重要。
Tauri的核心作用：它充当了前端（Next.js静态文件）和核心（Rust）之间的桥梁。通过Tauri提供的安全IPC（进程间通信）机制，前端JavaScript可以调用后端Rust暴露的命令（commands），例如读取本地文件、执行Git操作、管理进程等。Tauri还负责窗口管理、系统托盘、原生菜单等桌面应用特有的功能。在Codeg桌面版中，Tauri是唯一的“运行时”。

核心层 (Rust):

为什么用Rust重写核心逻辑？这是Codeg敢于处理多种本地智能体数据、实现高性能文件解析和提供稳定Web服务的底气所在。
1. 性能与安全：Rust的内存安全性和零成本抽象，使得处理大量并发文件读取、解析JSON/数据库（如OpenCode的SQLite）、管理WebSocket连接等操作既快又稳，几乎不会出现内存泄漏或数据竞争。
2. 跨平台一致性：Rust编译出的二进制文件可以在Linux, macOS, Windows上原生运行，行为一致。这对于Codeg Server（独立服务器）的部署体验至关重要，用户只需要下载对应平台的二进制文件即可运行，无需担心运行时环境差异。
3. 强大的生态系统：Rust拥有优秀的HTTP服务器框架（如Axum，Codeg Server所用）、WebSocket库、ORM（SeaORM，用于SQLite操作）、以及各种系统交互库，足以构建一个健壮的后端服务。
共享核心：这是架构中最精妙的一点。无论是桌面版（Tauri）还是服务器版（codeg-server），它们都共享同一套Rust核心代码。这个核心包含了应用状态管理（AppState）、智能体客户端协议（ACP）管理器、各种会话解析器（Parser）、聊天频道逻辑、Git/文件树/终端操作集成、MCP市场配置以及数据库（SeaORM + SQLite）访问。Tauri桌面版通过IPC调用这些核心功能；而codeg-server则使用Axum框架构建HTTP和WebSocket服务器，通过网络请求来调用相同的核心功能。这就实现了“一次编写，多处运行”，极大降低了维护成本。

这种架构带来的直接好处是部署形态极其灵活：你可以把它当成本地桌面应用用，享受最好的集成体验；也可以把它部署成团队共享的Web服务，实现远程协作；还能用Docker一键部署，方便在云服务器上运行。

2.2 核心概念解析：ACP、MCP与智能体集成

Codeg能整合多个智能体的关键在于它遵循并利用了现有的协议和标准，而不是重新发明轮子。

ACP (Agent Client Protocol):这是Codeg能够与Claude Code、Codex CLI等对话的基石。ACP定义了一套智能体（Agent）与其客户端（Client）之间的通信规范。简单理解，一个符合ACP的智能体在本地运行时会生成结构化的会话日志或状态文件。Codeg的核心Rust模块中包含了针对每个智能体的解析器（Parser）。这些解析器知道去哪里找这些文件（依赖环境变量或默认路径，如下表），并理解其格式，从而将原始的、分散的对话记录，提取、清洗并聚合成Codeg内部统一的对话模型，展示在优雅的GUI中。

MCP (Model Context Protocol) / Skills 管理：MCP是另一个新兴的协议，旨在为AI模型提供访问工具、数据库等上下文信息的标准方式。Codeg内置了MCP管理功能，这意味着你可以在Codeg内浏览、安装、配置各种MCP服务器（比如连接数据库、访问日历、调用API的工具）。同时，Codeg还有自己的“Skills”管理系统。Skills可以理解为一些预定义的工作流或自动化脚本，可以在全局或单个项目范围内启用。这相当于为你的AI智能体军团装备了更强大的、可定制的“武器库”。

支持的智能体与路径解析：下表清晰地列出了Codeg目前支持的主流智能体及其数据文件路径。理解这个对排查“为什么Codeg没找到我的对话”很有帮助。

智能体	环境变量路径	macOS / Linux 默认路径	Windows 默认路径	解析关键
Claude Code	`$CLAUDE_CONFIG_DIR/projects`	`~/.claude/projects`	`%USERPROFILE%\.claude\projects`	解析项目文件夹内的会话文件
Codex CLI	`$CODEX_HOME/sessions`	`~/.codex/sessions`	`%USERPROFILE%\.codex\sessions`	解析会话日志文件
OpenCode	`$XDG_DATA_HOME/opencode/opencode.db`	`~/.local/share/opencode/opencode.db`	`%USERPROFILE%\.local\share\opencode\opencode.db`	直接读取SQLite数据库
Gemini CLI	`$GEMINI_CLI_HOME/.gemini`	`~/.gemini`	`%USERPROFILE%\.gemini`	解析配置和缓存目录
OpenClaw	—	`~/.openclaw/agents`	`%USERPROFILE%\.openclaw\agents`	解析智能体定义文件
Cline	`$CLINE_DIR`	`~/.cline/data/tasks`	`%USERPROFILE%\.cline\data\tasks`	解析任务数据文件

重要提示：Codeg在查找路径时，会优先使用环境变量。如果环境变量未设置，则回退到上表中的默认路径。如果你自定义了某个智能体的数据存储位置，务必设置对应的环境变量，否则Codeg将无法索引到你的历史对话。

2.3 数据流与通信模型

理解了组件，我们再看看它们之间如何“对话”。

桌面模式 (Tauri):
- 用户在前端界面操作（如点击“刷新对话”）。
- 前端通过Tauri提供的invoke函数，调用一个预定义的Rust命令（例如refresh_conversations）。
- Tauri的Rust侧收到调用，执行共享核心中的相应业务逻辑（如遍历上述路径，调用各解析器）。
- Rust核心处理完成后，将结果（如解析后的对话列表）通过Tauri IPC返回给前端。
- 前端更新UI。整个过程发生在本地进程内，速度极快，且无需网络。
服务器模式 (codeg-server):
- 用户从浏览器访问http://服务器IP:3080。
- 前端静态文件由Rust Axum服务器托管并发送给浏览器。
- 用户在浏览器前端操作。
- 前端通过fetch发起HTTP API请求，或建立WebSocket连接，与后端的Axum服务器通信。
- Axum服务器接收到请求后，调用同一个共享Rust核心来处理业务逻辑。
- 处理结果通过HTTP响应或WebSocket消息返回给前端。
- 前端更新UI。这个过程走网络，但核心业务逻辑代码与桌面版完全一致。

这种设计确保了功能的一致性，无论你使用哪种部署方式，都能获得相同的核心体验。服务器模式只是多了一层HTTP/WS的网络封装。

3. 核心功能深度解析与实操要点

Codeg的功能相当丰富，但核心可以归结为四大支柱：智能体聚合、并行开发、项目脚手架、聊天频道集成。我们逐一深入。

3.1 智能体聚合与对话管理：从混乱到秩序

这是Codeg的立身之本。安装并启动Codeg后，第一件事就是让它“发现”你的智能体。

初始配置与索引：首次打开Codeg，你需要进入Settings -> Agents界面。这里Codeg会尝试根据默认路径和环境变量自动扫描已安装的智能体。但根据我的经验，自动扫描不一定100%成功，特别是当你使用非标准安装或自定义了配置目录时。

实操技巧：手动检查路径。如果某个智能体没有显示对话，首先去终端里echo一下对应的环境变量，比如echo $CLAUDE_CONFIG_DIR，看看是否设置正确。或者直接去默认路径下看看是否存在数据文件。例如，对于OpenCode，你可以用sqlite3 ~/.local/share/opencode/opencode.db .tables快速确认数据库能否访问。
注意事项：文件权限问题。在Linux/macOS上，确保运行Codeg的用户有权限读取这些路径下的文件。特别是如果某些智能体是以其他用户身份（如通过sudo）运行的，其生成的文件可能对当前用户不可读。这时需要调整文件权限或使用相同的用户运行所有工具。

对话聚合视图：索引成功后，所有智能体的对话会按时间顺序或项目归属聚合在主界面。这个视图的强大之处在于：

结构化渲染：原始的、可能夹杂着各种标记的AI输出，被渲染成更易读的格式，代码块有高亮，系统指令和用户消息区分清晰。
跨智能体搜索：你可以在一个地方搜索所有对话历史，再也不用一个个工具去翻了。
会话状态管理：可以清晰地看到哪些会话正在进行中，哪些已结束。

3.2 基于Git Worktree的并行开发流

这是Codeg为专业软件开发流程量身定做的功能，解决了“我想用AI同时尝试实现两个不同功能，但又不想弄乱主分支”的痛点。

Git Worktree 是什么？简单说，git worktree允许你从同一个Git仓库克隆出多个独立的工作目录（working tree），每个目录可以切换到不同的分支。它们共享同一个.git仓库对象数据库，但工作区完全隔离。这意味着你可以在一个工作区修改feature-a分支，同时在另一个工作区编译和测试feature-b分支，互不影响。

Codeg如何集成它？Codeg将git worktree的命令行操作封装成了可视化的流程：

在Codeg中打开你的项目仓库。
在Git面板中，你可以看到“Worktrees”选项。
点击“添加工作树”，指定一个新分支名和路径（Codeg通常会建议一个合理的路径，如../<project-name>-<branch-name>）。
Codeg会在后台执行git worktree add命令，并在其文件树中为你打开这个新的工作目录视图。
现在，你可以在这个新的工作树视图中，让AI智能体基于这个新分支进行代码生成和修改，而你的主工作区保持不变。

实操心得与避坑指南：

路径规划：建议为worktree目录建立一个固定的父文件夹，比如~/worktrees/，方便管理。Codeg默认可能会创建在项目同级目录，要留意不要误删。
清理工作：当并行开发完成后，记得在Codeg内或使用git worktree remove命令清理不再需要的工作树，避免磁盘空间浪费和目录混乱。
与IDE配合：Codeg的worktree是一个独立的文件夹，你可以用其他IDE（如VSCode）单独打开它。但要注意，某些IDE的Git插件可能对worktree支持不完美，在Codeg内进行Git操作是最稳妥的。

3.3 Project Boot：可视化项目脚手架

对于前端项目，尤其是基于React/Next.js和组件库的快速启动，Codeg的“Project Boot”功能能极大提升效率。

工作流程：

在Codeg中启动“Project Boot”，你会看到一个分屏界面。
左侧配置面板：像搭积木一样选择你的项目偏好。这包括：
- 样式框架：目前主要支持shadcn/ui，这是一个可以让你将精美组件复制到项目中的现代化组件库。
- 颜色主题：从预设的亮色/暗色主题或自定义调色板中选择。
- 图标库：选择Lucide、Radix Icons等。
- 字体、边框圆角等视觉细节。
右侧实时预览：每调整一个配置，右侧的iframe会实时更新，展示应用了这些样式和主题的组件大概是什么样子。这比凭空想象或事后调整要直观得多。
一键生成：配置满意后，选择基础模板（Next.js, Vite, React Router, Astro, Laravel等）、包管理器（pnpm, npm, yarn, bun），点击“Create Project”。
幕后魔法：Codeg会调用shadcn init命令，并应用你所有的配置预设，在指定目录生成一个结构完整、样式统一的新项目。之后，这个新项目会自动在Codeg的工作区中打开。

注意事项：

包管理器检测：Codeg会检测你系统里安装的包管理器及其版本，并在UI中显示。确保你选择的包管理器已正确安装。
网络依赖：生成过程需要从npm仓库下载shadcn/ui的模板和依赖，请保持网络通畅。
未来扩展：目前主要围绕shadcn/ui，但标签页设计意味着未来可以轻松加入其他类型的项目模板（如后端API模板、Chrome扩展模板等）。

3.4 Chat Channels：将AI智能体接入你的工作聊天

这是Codeg最具创新性和实用性的功能之一，它打破了工具间的壁垒，让AI协作变得无处不在。

核心价值：想象一下，你正在飞书群里和同事讨论一个技术方案，突然想到一个功能点可以用AI辅助实现。传统方式是：切出聊天窗口 -> 打开Codeg或终端 -> 找到项目 -> 输入任务描述 -> 等待 -> 复制结果 -> 切回飞书粘贴。而在Codeg的Chat Channels集成下，流程变为：在飞书群里输入/task 我们需要一个用户登录的API接口，使用JWT鉴权-> AI智能体开始工作 -> 进度和结果实时推送到飞书群。所有操作在聊天环境内完成，上下文不中断。

支持的平台与协议：

频道	协议	集成方式	关键点
Telegram	Bot API (HTTP长轮询)	内置	需要向`@BotFather`申请一个Bot Token，安全性高，推送格式支持Markdown。
Lark (飞书)	WebSocket + REST API	内置	需要在飞书开放平台创建企业自建应用，获取`App ID`和`App Secret`。配置稍复杂，但支持富文本卡片消息。
iLink (微信)	WebSocket + REST API	内置	通过扫描二维码登录网页版微信实现，无需申请机器人，但存在因风控导致断连的风险。

配置步骤详解（以Telegram为例）：

创建Bot：在Telegram中搜索@BotFather，发送/newbot，按提示操作，最终获得一个形如1234567890:ABCdefGhIJKlmNoPQRsTUVwxyZ的Token。
在Codeg中添加频道：进入Settings -> Chat Channels，点击“Add Channel”，选择Telegram。
填入Token：将上一步获得的Token粘贴进去。Codeg会使用操作系统的密钥环（Keyring）来安全存储这个Token，不会明文保存在配置文件或日志中。
配置事件过滤：你可以选择接收哪些类型的通知（例如，只接收任务完成通知，忽略每个工具调用细节）。
连接与测试：保存后，Codeg会尝试连接Telegram Bot。连接成功后，给你创建的Bot发送任意消息，Codeg会回复一个连接成功的确认信息。

常用聊天命令：一旦连接成功，你就可以在聊天软件中像操作命令行一样与你的AI智能体交互：

/folder– 选择要操作的项目目录。
/agent– 选择使用哪个AI智能体（如Claude Code, Codex）。
/task <任务描述>– 开始一个新任务。例如/task 为当前项目的utils.js文件添加一个防抖函数。
/resume– 继续上一个会话。
/cancel– 取消当前正在进行的任务。
/sessions– 列出所有活跃的会话。
/approve或/deny– 当AI请求执行某个工具（如写文件）需要权限时，用此命令批准或拒绝。
/search <关键词>– 在所有对话历史中搜索。
/today– 查看今天的活动摘要。
/help– 获取命令帮助。

安全与隐私提醒：

Token安全：务必通过Codeg的图形界面或受信任的环境变量来配置Token，不要泄露给他人。
权限控制：在聊天中审批AI的写文件、运行命令等权限时，务必清楚AI要做什么。可以临时批准单次，也可以对可信操作设置/approve always。
信息范围：注意你连接的工作群组。AI生成的内容和对话历史可能会被推送到群里，确保群组成员都有权知晓这些信息。

4. 部署模式详解：从桌面到服务器

Codeg提供了极其灵活的部署选项，适应从个人到团队的不同场景。

4.1 桌面应用部署（Tauri）

这是最直接的方式，适合个人在本地开发机上使用。

# 从源码构建（需要Rust/Node.js环境） pnpm install pnpm build # 构建前端静态文件 pnpm tauri build # 构建桌面应用，输出在 src-tauri/target/release/ 下 # 或者，直接从 GitHub Releases 下载对应平台的安装包（.deb, .dmg, .msi等）

桌面版的优势是深度集成系统，访问本地文件路径最方便，性能也最好。

4.2 独立服务器部署（codeg-server）

这是实现远程访问和团队共享的关键。codeg-server是一个独立的、无GUI的二进制文件。

几种安装方式：

一键安装脚本（Linux/macOS）：
```
curl -fsSL https://raw.githubusercontent.com/xintaofei/codeg/main/install.sh | bash # 安装后直接运行 codeg-server
```
这个脚本会自动检测系统架构，下载最新的预编译二进制文件（已包含前端静态资源）到~/.local/bin（或自定义目录）。
手动下载发布包：去GitHub Releases页面，下载对应平台的压缩包（如codeg-server-linux-x64.tar.gz），解压后运行其中的可执行文件。注意：你需要确保解压后的目录里包含web或out文件夹（前端资源），或者通过CODEG_STATIC_DIR环境变量指定其路径。

从源码构建：

pnpm install && pnpm build cd src-tauri cargo build --release --bin codeg-server --no-default-features # 运行，并指定前端资源路径 CODEG_STATIC_DIR=../out ./target/release/codeg-server

服务器配置：运行codeg-server时，可以通过环境变量进行配置：

CODEG_PORT=8080 CODEG_HOST=127.0.0.1 CODEG_DATA_DIR=/path/to/data codeg-server

CODEG_PORT: 服务端口，默认3080。
CODEG_HOST: 绑定地址，默认0.0.0.0（监听所有网卡）。如果部署在公网服务器，强烈建议配合Nginx等反向代理设置访问控制，不要直接暴露在公网。
CODEG_TOKEN: 访问令牌。如果不设置，服务器启动时会生成一个随机Token并打印在控制台。你必须使用这个Token才能从浏览器访问Web界面。这是最基本的安全认证。
CODEG_DATA_DIR: SQLite数据库等数据的存储目录，默认在~/.local/share/codeg。
CODEG_STATIC_DIR: 前端静态文件目录。

访问方式：服务器启动后，在浏览器访问http://<服务器IP>:<端口>，会跳转到登录页，输入启动时显示的Token即可进入Web界面。

4.3 Docker容器化部署

对于追求部署一致性和便捷性的用户，Docker是最佳选择。

使用Docker Compose（推荐）：项目根目录提供了docker-compose.yml示例。

version: '3.8' services: codeg: image: ghcr.io/xintaofei/codeg:latest container_name: codeg restart: unless-stopped ports: - "3080:3080" environment: - CODEG_TOKEN=your-strong-secret-token-here # 务必修改！ # - CODEG_PORT=3080 # - CODEG_HOST=0.0.0.0 volumes: - codeg-data:/data # 挂载本地项目目录到容器内，这样Codeg就能访问你的代码了 - /path/to/your/projects:/projects:ro # 只读挂载，更安全 # - /path/to/your/projects:/projects # 读写挂载，允许AI修改代码 volumes: codeg-data:

然后运行docker compose up -d即可。

直接使用Docker run：

docker run -d \ --name codeg \ -p 3080:3080 \ -v codeg-data:/data \ -v /home/user/code:/projects \ -e CODEG_TOKEN=your-secret \ ghcr.io/xintaofei/codeg:latest

Docker部署要点：

镜像特点：官方镜像采用多阶段构建，最终基于轻量的Debian镜像，包含了git和ssh，以便在容器内进行Git仓库操作。
数据持久化：务必通过-v codeg-data:/data将/data卷持久化，否则容器重启后所有配置和数据库都会丢失。
项目目录挂载：为了让容器内的Codeg能访问你宿主机的代码，需要将项目目录挂载到容器内（如/projects）。你可以根据需求选择只读（:ro）或读写挂载。
网络与权限：如果容器内的AI智能体需要访问宿主机的服务（如本地数据库），可能需要配置更复杂的网络模式（如host）或额外挂载Unix socket。

5. 常见问题排查与实战技巧

在实际使用和部署Codeg的过程中，你可能会遇到一些问题。这里我总结了一些常见情况和解决思路。

5.1 智能体对话无法加载或为空

这是最常见的问题。

症状：在Codeg的Agents页面，某个智能体显示“No conversations”或一直加载。
排查步骤：
1. 确认路径：首先确认该智能体确实在你的系统上安装并运行过，产生了会话数据。
2. 检查环境变量：在终端执行echo $智能体环境变量名（如echo $CLAUDE_CONFIG_DIR）。如果为空，Codeg会回退到默认路径。你可以在Codeg的设置中尝试手动指定路径（如果支持），或者在启动Codeg前在终端设置好环境变量。
3. 检查文件权限：使用ls -la <路径>查看数据文件的所有者和权限。确保运行Codeg的用户有读取权限。必要时用chmod或chown调整。
4. 查看日志：运行Codeg时打开开发者工具（桌面版）或查看服务器日志（codeg-server），看是否有关于文件读取或解析的错误信息。
5. 智能体版本兼容性：某些智能体更新后，其数据存储格式可能发生变化。确保你使用的Codeg版本支持当前智能体的数据格式。关注Codeg的Release Notes。

5.2 聊天频道连接失败

Telegram Bot 无响应：
- 确认Bot Token正确无误，没有多余空格。
- 在Telegram中搜索你的Bot用户名，并发送/start命令初始化。有些Bot需要此步骤。
- 检查网络，确保服务器可以访问api.telegram.org。
飞书（Lark）应用授权失败：
- 确认在飞书开放平台创建的是“企业自建应用”。
- 检查应用的“权限管理”是否开启了“获取应用访问凭证”和“接收消息”等必要权限。
- 确保填写的App ID和App Secret正确。
- 飞书需要配置“事件订阅”和“消息卡片回调地址”。Codeg作为服务器，需要有一个公网可访问的URL（或通过内网穿透工具）来接收飞书的回调。这是配置中最复杂的一环。
微信（iLink）频繁断连：
- 网页版微信的稳定性受腾讯风控策略影响较大，不是长期稳定的选择，仅适合临时测试。
- 如果必须使用，考虑在稳定的服务器（固定IP）上运行Codeg Server，并确保该IP地址没有异常登录行为。

5.3 服务器部署后无法访问Web界面

检查Token：首次访问时，必须使用服务器启动时在控制台输出的Token。如果忘记了，重启服务会生成新的。
检查防火墙/安全组：确保服务器防火墙或云服务商的安全组规则允许了对应端口（默认3080）的入站流量。
检查绑定地址：如果CODEG_HOST设置为127.0.0.1，则只能从服务器本机访问。需要远程访问应设置为0.0.0.0。

使用反向代理（生产环境必备）：强烈建议使用Nginx或Caddy作为反向代理，处理SSL/TLS（HTTPS）、域名绑定、访问日志和基础的安全防护。

# Nginx 示例配置片段 server { listen 443 ssl; server_name codeg.yourdomain.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://127.0.0.1:3080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # 支持WebSocket proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

5.4 性能优化与日常使用技巧

会话数据清理：Codeg会索引所有智能体的历史对话，长期使用后数据库可能会变大。定期在Codeg设置中清理不再需要的项目或旧会话，可以提升加载速度。
工作树管理：养成及时清理已完成功能的git worktree的习惯，避免磁盘空间被大量临时分支占用。
多项目切换：Codeg可以同时打开多个项目窗口。利用这个特性，将不同的工作上下文（如前端项目、后端项目、文档项目）分开，让不同的AI智能体专注于不同的领域。
自定义Skills：深入研究Codeg的Skills系统，尝试创建一些自定义技能。例如，可以创建一个“代码审查”技能，自动将生成的代码与项目的lint规则和测试套件进行比对；或者创建一个“提交信息生成”技能，根据代码变更自动生成规范的Git提交信息。

Codeg的出现，标志着一个新的趋势：AI编程工具正从单一的、孤立的命令行工具，向集成的、协作的、平台化的方向发展。它不仅仅是一个聚合器，更是一个以开发者为中心的工作流引擎。通过将本地AI能力、版本控制、即时通讯和可视化操作深度融合，它为我们勾勒出了未来人机协同编程的一个非常现实的图景。无论你是想提升个人效率，还是为团队搭建一个AI辅助开发平台，Codeg都提供了一个坚实且高度可扩展的起点。