Codeg 开源新版：当 IDE 学会「群聊」和「找专家」

行业快讯

开源多智能体 IDE Codeg 近日发布重大更新，引入 IM 消息通道和专家技能体系，让多个 AI Agent 像团队协作一样在 IDE 内沟通分工，支持桌面端和 Docker 部署。

Codeg 开源新版：当 IDE 学会「群聊」和「找专家」

一个开源项目正在试图回答一个问题：如果写代码不是一个人和一个 AI 的对话，而是一群 AI 专家在群里协作，会怎样？

Codeg 近日推送了一次大版本更新。这个专注代码生成的多智能体 IDE，这次加了两个值得关注的东西——IM 消息通道和专家技能体系。听起来像是把企业微信的群聊逻辑搬进了开发工具里，但实际做的事情比这有意思得多。

先说 IM 通道：Agent 之间终于能「说话」了

过去大多数 AI 编程工具的架构是线性的——你给一个 prompt，模型返回一段代码，顶多加个 chain-of-thought 做多步推理。Codeg 这次做的事情不太一样：它在多个 Agent 之间建了一条消息总线。

什么意思？你可以把它理解成一个内部聊天室。一个负责架构设计的 Agent 产出方案后，不是直接丢给你，而是先发到通道里，让负责代码实现的 Agent 接收、再让负责测试的 Agent 审查。每个 Agent 都能看到上下文，都能基于前面的讨论做出反应。

这跟学术界讨论的 Multi-Agent Debate 思路一脉相承——多个专业化智能体通过内部辩论和协商来提升输出质量。区别在于，Codeg 把这个概念落到了一个可以跑起来的 IDE 产品里。

从社区反馈来看，IM 通道目前还有些粗糙。有用户反映设置里明明开启了功能，但会话框里显示未开启，说明前后端状态同步还有 bug 要修。不过对于一个开源项目来说，这属于正常的迭代节奏。

再说专家技能：给 Agent 发「职业资格证」

这是这次更新里我觉得更有想象力的部分。

Codeg 引入了一套「专家技能」机制。简单说，你可以给不同的 Agent 配置不同的技能包——有的擅长 Python 后端，有的专精前端组件，有的专门做代码审查，有的负责写测试用例。每个 Agent 不再是一个通用的「什么都能聊两句但什么都不精」的助手，而是有明确分工的专家角色。

这解决了当前 AI 编程工具的一个核心痛点：上下文污染。当你用一个通用 Agent 既写业务逻辑又写单元测试还要帮你 review 代码时，它的注意力是分散的，prompt 越来越长，输出质量不可避免地下降。把职责拆开，每个 Agent 只关注自己擅长的领域，理论上能显著提升生成质量。

这个思路其实和软件工程里的「单一职责原则」异曲同工——只不过这次被约束的不是代码模块，而是 AI Agent 本身。

Codeg 多智能体架构示意图，展示 IM 通道连接多个专家 Agent 的协作流程

部署方式：桌面端和 Docker 都给你了

工程层面，Codeg 这次提供了三种部署方式：

  • 桌面端客户端，开箱即用
  • 服务端部署，适合团队共享
  • Docker 镜像，一行命令拉起来

对于想在团队内部试水多智能体编程的技术负责人来说，Docker 部署是最实际的选择。拉个镜像，配好模型 API，就能让团队成员共享同一套 Agent 配置和技能体系。

说到模型 API，Codeg 作为 IDE 本身不绑定特定模型，底层需要接大语言模型来驱动 Agent。如果你同时想用 GPT 做架构设计、Claude 做代码生成、DeepSeek 做中文文档——这种多模型混用的场景，通过 OpenAI Hub 这类 API 聚合服务一个 endpoint 就能搞定，不用给每个 Agent 单独配不同的 API 地址。

跟竞品比，Codeg 在什么位置？

坦率地说，Codeg 目前的完成度和 Cursor、Windsurf 这些商业产品还有明显差距。后者在代码补全、上下文理解、用户体验打磨上已经做了大量工作，而 Codeg 连基础的状态同步 bug 都还没修干净。

但 Codeg 走的路线不一样。Cursor 们本质上还是「单 Agent + 强上下文」的思路——一个很聪明的助手帮你干活。Codeg 押注的是「多 Agent 协作」——一个团队帮你干活。这两条路线谁更有前途，现在下结论还太早。

从技术趋势看，多智能体协作确实是 2025-2026 年 AI 应用层最热的方向之一。微软的 AutoGen、CrewAI、MetaGPT 都在探索类似的范式。Codeg 的价值在于，它把这个范式直接做进了 IDE，而不是停留在框架层面让开发者自己搭。

不过，多 Agent 架构也带来了新的复杂性。Agent 之间的通信开销、冲突解决、技能路由的准确性，这些都是工程上的硬骨头。IM 通道里如果两个 Agent 对同一段代码给出矛盾的建议，谁说了算？目前 Codeg 似乎还没有给出清晰的仲裁机制。

一个更大的问题

多智能体 IDE 真正要回答的问题不是「能不能跑起来」，而是「比单 Agent 好多少」。

如果三个 Agent 协作生成的代码质量，只比一个 Claude Opus 直接生成的好 5%，但延迟多了 3 倍、token 消耗多了 4 倍，那这笔账算不过来。Codeg 社区目前还没有公布系统性的 benchmark 对比数据，这是后续需要补上的。

但反过来想，如果多 Agent 协作能在复杂项目（比如涉及前后端联调、数据库迁移、API 设计的全栈任务）上展现出明显优势，那它的价值就不只是一个 IDE，而是一种新的软件开发范式的雏形。

这个方向值得持续关注。

如果你想快速体验 Codeg 的多 Agent 能力，接入模型 API 时可以参考以下示例。以 OpenAI Hub 兼容格式为例，配置一个专家 Agent 的模型调用：

import openai

client = openai.OpenAI(
    api_key="your-openai-hub-key",
    base_url="https://api.openai-hub.com/v1"
)

# 为「代码审查专家」Agent 配置系统提示
response = client.chat.completions.create(
    model="claude-sonnet-4-20250514",
    messages=[
        {
            "role": "system",
            "content": "你是一个资深代码审查专家，专注于发现潜在 bug、性能问题和安全漏洞。只输出审查意见，不要重写代码。"
        },
        {
            "role": "user",
            "content": "请审查以下 Python 函数：\ndef get_user(id):\n    return db.execute(f'SELECT * FROM users WHERE id={id}')\n"
        }
    ]
)

print(response.choices[0].message.content)

不同的专家 Agent 可以指定不同的模型——架构设计用推理能力强的，代码生成用速度快的，按需搭配。

参考来源：