AI Research 技术调研

智谱 CodeGeeX：闭源 VS Code/JetBrains 编码 agent，本地 FastAPI + 真 MCP 协议驱动

31分钟阅读

智谱 CodeGeeX

一句话定位

CodeGeeX 是智谱 AI 发布的 VS Code / JetBrains 编码插件（VS Code Marketplace 发布方 aminer，插件 id aminer.codegeex，安装量 1,299,732），当前版本（v2.27.6，2025-09-01 发布）内置了一个基于真实 Model Context Protocol（MCP）SDK（mcp>=1.6.0）驱动的单 agent，工具执行走本地 FastAPI/uvicorn 服务（localhost:11435），核心 agent 循环逻辑因 Pyarmor 字节码加密而不可读——本 dossier 是在”闭源 + 加密”约束下能做到的最深源码级调研。

核心架构总览（目录结构关键路径 + 引用的 commit）

重要澄清（仓库身份纠错）：任务给出的线索 github.com/THUDM/CodeGeeX4 只是模型发布仓库（commit 480f792bf9a57cfa8ccad84ea4366badab99bee3），内容是 CodeGeeX4-ALL-9B 模型的使用 demo（transformers/vLLM/Candle/Ollama 调用示例、LangChain/LlamaIndex RAG demo、Jupyter 沙箱 interpreter demo、repo-QA demo），不含任何 harness/agent 代码。真正的 harness 是 VS Code/JetBrains 插件本体：

  • 曾经公开的插件源码仓库 github.com/CodeGeeX/codegeex-vscode-extension（commit 3bbc5305bae91928152eb76ef41c4b822edb3c56，tag 1.1.2，最后 push 于 2023-01-29）严重过时——只有行内补全 + 翻译 + prompt-mode + 交互模式，完全没有 chat/agent/MCP。
  • 当前真实生产 harness 闭源，在智谱私有 GitLab（dev.aminer.cn）上开发，由插件 .gitmodules 暴露的 4 个私有子模块构成（均不可公开访问）： 
    webview-ui   → dev.aminer.cn/codegeex/codegeex-extension-siderbar.git
welcome-page → dev.aminer.cn/codegeex/codegeex-extension-welcome.git
project-map  → dev.aminer.cn/codegeex/project-map.git
agent        → dev.aminer.cn/codegeex/codegeex-mcp.git   ← 真正的 agent 后端
  • 为获得当前版本的真实证据，本次调研直接从 Marketplace CDN 下载生产 VSIX 包并解压： https://aminer.gallerycdn.vsassets.io/extensions/aminer/codegeex/2.27.6/1756716402649/Microsoft.VisualStudio.Services.VSIXPackage（经 Marketplace Gallery API extensionquery 确认版本 2.27.6、lastUpdated 2025-09-01T09:01:40.14Z、installs 1,299,732、engines.vscode: ^1.81.0）。

VSIX 内部结构：

dist/extension.js              — VS Code 扩展宿主代码，webpack 压缩但未混淆（变量名被打乱，字符串/逻辑完整、可 grep）
dist/agent/                    — Python agent 后端（即 codegeex-mcp 子模块，随包 vendor 进来）
  ├── main.py, pyarmor_runtime_000000/         — Pyarmor 9.1.8 字节码加密：文件内容不可读，但文件/模块/类名明文
  ├── codegeex_mcp/agent/converse_agent.py     — 推测的对话式 agent 循环实现（加密，无法读逻辑）
  ├── codegeex_mcp/kernel/mcp_kernel.py         — MCP 内核（加密）
  ├── codegeex_mcp/kernel/tool_finder.py         — 工具选择/路由（加密）
  ├── codegeex_mcp/client/mcp_client.py, tools_manager.py
  ├── codegeex_mcp/consts/system_prompt.py       — agent 模式系统提示组装（加密，内容不可读）
  ├── codegeex_mcp/session/agent_session.py, manager.py
  ├── configs/mcp_config.json                    — 内置 3 个 MCP server 注册表（明文，见"工具体系"）
  ├── configs/user_mcp_config.json                — 用户自定义 MCP server 注册表（明文，默认 `{"mcpServers": {}}`）
  ├── configs/state_config.json                   — agent 后端自身版本号 `"version": "1.3.11"`（与插件 2.27.6 是两套版本号）
  ├── log.yaml                                    — Python logging 配置（明文 YAML）
  └── mcp_tools/codegeex_mcp_tools/src/codegeex_mcp_tools/
        frontend/tools/{list_dir,find_file,search_dir,search_file,edit_file,find_by_name,
                         view_file,replace_file_content,get_linter_errors,create_dir,
                         create_file,get_repo_structure,write_file}.py
        backend/tools/{add_comment,bug_fix,translate,unitest,review,explain}.py（部分文件名据 UI 字符串推断）
        terminal/tools/execute.py
webview-ui/dist/assets/index.js — 侧边栏 webview UI（压缩，含工具注册表/UI 文案等强证据字符串）
venv/codegeex-agent-linux-arm64.tar.gz — 预构建 Python venv（跳过 mamba 求解步骤）

所有 .py 文件均为 Pyarmor 加密字节码，只有文件/目录/模块/类名是明文证据，正文逻辑不可读。

Agent Loop（主循环 / 何时继续何时停）

  • 存在独立于普通 “Ask CodeGeeX” 问答的agentic chat 模式：UI 标签 agent:{title:"CodeGeeX Agent", description:"The CodeGeeX Agent can accurately analyze your requirements and quickly generate code or solve exceptions..."}，输入框 placeholder 为 “What do you need help coding?”。
  • Agent 状态机（tool.state）取值：success | error | terminated | processing —— 每轮是单发（single-flight）执行，没有可见的后台/异步多轮自主规划器。
  • Agent 后端进程自身的引导/生命周期状态机（从 extension.js 中提取的枚举常量）：copy_agent_files → create_mamba_env → install_requirements → setup_mcp_tools → start_agent，失败/重试态包括 start_agent_failed、start_fresh_setup、full_setup_failed、start_python_ready_recovery、python_ready_quick_start_success、stop_agent。也就是说 harness 首次使用时会在用户机器上安装并托管自己的本地 Python agent 运行时（conda/mamba 建环境 + pip install -r requirements.txt），而不只是调远程 API。
  • 真正的逐步推理/工具调用循环位于加密文件 dist/agent/codegeex_mcp/agent/converse_agent.py 与 dist/agent/codegeex_mcp/kernel/mcp_kernel.py —— 循环逻辑本身不可读（Pyarmor 字节码），只能确认存在专职的 “conversational agent” + “MCP kernel” 模块对来实现循环。
  • 本地后端服务：FastAPI/uvicorn（agent_requirements.txt: fastapi==0.115.6, uvicorn>=0.32.0），监听 http://localhost:11435（extension.js 中硬编码端口常量，紧邻 envName:"codegeex-agent", entry:"CodeGeeXAgent.py", venvPath:"venv"）。插件本体是一个瘦客户端，通过本地 HTTP 与这个服务通信。
  • 未发现”无需用户重新提示的多轮自主循环”证据（package.json 配置项 / l10n 字符串中未找到 “max iterations” 或 “continue automatically” 之类设置）。

记忆与上下文管理（压缩、长期记忆、会话持久化）

  • @-mention 上下文提供器（webview bundle 中找到）：@code、@file、@folder、@repo、@workspace —— 用户显式挂载上下文范围，而非 agent 全自动检索。
  • @repo/@workspace = 对已索引代码库的 RAG：package.json 中有 Codegeex.RepoIndex 配置项；索引流程需用户同意，确认文案（l10n 字符串）：“Please allow us to read the code repository and create an index. The indexing results will only be used to provide contextual information for your Q&A and completions, and will not be used for model training. You can delete the index data in the settings at any time…”，附 codegeex.cn/privacypolicy 链接。extension.js 中还有 AuthCodebase/GetCodebaseState/SyncCodebaseState 等内部消息类型，暗示代码库索引是服务端授权（绑定登录/license），非纯本地行为。
  • CHANGELOG（2.15.0–2.18.0 条目）记录了 @workspace 的演进：2.15.0 引入；2.16.0”提升项目结构问答的上下文信息”；2.17.0”提升 @workspace…索引工作区文件更快更准”；2.18.0 加入 “Interactive Code Map”（由 project-map 子模块 / codegeex.explorer.projectMap 命令支撑）—— 这是第二种、互补的记忆机制（结构地图 vs. 语义 RAG 索引）。
  • 会话/聊天历史持久化：extension.js 中一个类似 HistoryManager 的类将数据落盘到 globalStorageUri/agent/history.json（VS Code 每插件全局存储目录），文件不存在时自动创建为 {}。从客户端视角看，这是纯本地会话历史，没有观察到云同步的轨迹存储。
  • 上下文压缩/摘要：未找到证据。对两个 JS bundle grep compress*/summariz*/truncat*/contextWindow/maxTokens/tokenLimit 均无实质命中（唯一一处 "truncate" 命中是 webview bundle 内置的 SQL/Perl 语法高亮关键词字典误报，非应用逻辑）。如果压缩机制存在，只能在加密的 Python agent 内部，客户端不可见。
  • Codegeex.RecentFiles 缓存（globalState key codegeex.recentFiles）是”最近打开文件”轻量列表，服务于补全上下文，与聊天记忆无关。

工具体系（定义/调用协议/注册/权限）

  • 内置工具注册表（来自 webview UI l10n agent.builtInTools），共 20 个命名工具：executeCommand, createDir, createFile, editFileWithInstruction("Edit File"), findFile, getRepoStructure, listDir, searchDir, searchFile, viewFile, addComment, bugFix, explain, review, translate, unitest, analyzeWebpage, getLinterErrors, findByName(findFile 别名), replaceFileContent(Edit File 别名)。
  • 这些工具与 Python 模块/文件名一一对应，位于 dist/agent/mcp_tools/codegeex_mcp_tools/src/codegeex_mcp_tools/：
    • frontend/tools/: list_dir.py, find_file.py, search_dir.py, search_file.py, edit_file.py, find_by_name.py, view_file.py, replace_file_content.py, get_linter_errors.py, create_dir.py, create_file.py, get_repo_structure.py, write_file.py
    • backend/tools/: add_comment.py, bug_fix.py, translate.py, unitest.py, review.py（explain.py 据 UI 字符串推断，文件树中未逐一列出）
    • terminal/tools/: execute.py （以上均为文件名证据，正文因 Pyarmor 加密不可读。）
  • 工具调用协议 = 真实 Model Context Protocol（MCP），且产品文案中明确以此命名：webview 帮助文本写道 “MCP(Model Context Protocol) is a method for providing new tools to the CodeGeeX Agent.” agent_requirements.txt 锁定 mcp>=1.6.0（Anthropic 发起的官方 MCP Python SDK），确认这不是自研协议的”套壳”，而是真 MCP 规范。
  • 内置 3 个 MCP server，注册在 dist/agent/configs/mcp_config.json（原文，已核实）： 
    {"mcpServers": {
  "frontend_server": {"command": "python", "args": ["-m", "codegeex_mcp_tools.frontend"]},
  "backend_server":  {"command": "python", "args": ["-m", "codegeex_mcp_tools.backend"]},
  "terminal":        {"command": "python", "args": ["-m", "codegeex_mcp_tools.terminal"]}
}}
    frontend_server = 编辑器/文件系统类工具（查看/编辑/搜索/创建文件、仓库结构、linter 错误），backend_server = “工具箱”式代码变换工具（注释/修 bug/解释/审查/翻译/单测——与旧版 System Prompt Guideline 的插件功能列表一致），terminal = shell 执行。
  • 用户可扩展：另有一个默认为空的 dist/agent/configs/user_mcp_config.json（{"mcpServers": {}}），配合产品内 UI（MCPPopover/MCPDrawer，“MCP Configuration” 标签页含 “MCP Servers” 与 “Templates” 子导航、“Add Server” 按钮、逐 server “Restart Server”）让用户注册自己的 MCP server、启停 server（extension.js 中 UC.toggleServer 会把 disabled 标志写回 user_mcp_config.json）、浏览预制 server 模板。
  • 工具调用权限模型：每次工具调用都在聊天 UI 中弹出逐次人工审批——确认 UI 原文字符串：prompt:"Please confirm whether to execute this command"（终端专用）与通用 promptForTool:"Please confirm whether to execute this tool"，配套控件 stop/skip/reject/cancel/accept/accept2("Accept")/accept3("Keep Changes")。package.json 配置 schema 中没有全局”自动批准”开关——审批似乎是 UI 层逐动作强制执行，而非可从设置策略化配置（至少客户端 bundle 层面看不到）。
  • 文件编辑类工具会生成可接受/拒绝/回滚的待定 diff：字符串 recover:"Recover Files"、revertAll:"Revert All"、acceptAll:"Accept All"，且新建会话/删除会话都带警告，如新建会话文案 “Creating a new session will accept the modified files and cannot be undone. Are you sure you want to continue?”（删除会话同样警告）——即结束会话会强制敲定任何待定的文件编辑接受/拒绝状态。

Prompt 设计（系统提示结构、动态组装）

  • 唯一完整公开、逐字可查的系统提示来自官方 guides/System_prompt_guideline.md（THUDM/CodeGeeX4 仓库），记录了底层模型使用的 ChatGLM 系特殊 token 提示格式： 
    <|system|>
{system prompt text}<|user|>
{query}<|assistant|>\n
    共 9 个任务专属系统提示，每个都是共同词干（“You are an intelligent programming assistant named CodeGeeX…“）加模式专属 Task: 后缀的小变体：Chat & General、Code Comments、Code Explanation、Code Translation（用 {target_language} 参数化）、Code Review、Code Fixing、Unit Testing、Candidate Questions（预测用户可能的下一个问题，输入最近 N 轮历史）、File Q&A。这是一种固定模板 + 任务专属指令拼接设计，不是动态分节组装的系统提示（这一层没有文档记录工具列表注入、记忆摘要注入之类的动态块）——不过 agent（工具使用）模式的系统提示大概率是在加密的 codegeex_mcp/consts/system_prompt.py 模块内组装的，该文件存在但内容不可读。
  • 官方指南明确了多轮策略：跨轮复用 Chat & General 系统提示；如果某一轮用了任务专属提示，“we recommend including the system prompt information in the same turn input” 供后续轮次使用（即任务模式对话中，系统提示不会自动携带/版本化跨轮传递——需要手动重新提供）。
  • 语言引导是提示词的后缀约定而非独立字段：在系统提示字符串末尾追加 “请用中文回答。” 或 “Please answer in English.”。

Router / 编排（任务分解、多 agent、子 agent）

  • 未发现任何多 agent 或子 agent 编排的证据（对两个 JS bundle grep subAgent/subagent/multiAgent/orchestrat*/planner/taskDecompos* 均为零命中）。产品呈现为单一 agent 人格（“CodeGeeX Agent”）+ 一个扁平工具注册表，不是 supervisor/worker 或 planner/executor 拆分。加密文件 dist/agent/codegeex_mcp/kernel/tool_finder.py 暗示存在某种扁平工具列表内的工具选择/路由，但这是标准的单 agent 工具选择，不构成多 agent 编排。
  • 参考实现 repodemo/（THUDM/CodeGeeX4 中的 chainlit repo-QA + “aicommiter” demo，见 repodemo/run.py、repodemo/utils/tools.py、repodemo/prompts/base_prompt.py）展示了一个单 agent ReAct 式工具使用循环——这是官方给出的一种参考/cookbook 设计模式，不必然等同于生产 harness 的实际编排代码（后者加密）。可作为”厂商自己的仓库级 agentic 任务参考架构”的旁证。

Skill / 插件体系

两个有重叠的”插件”概念：

  1. 固定内置的”插件功能”（模型自身术语，见 System_prompt_guideline.md）：代码注释、单元测试、代码解释、代码翻译、候选问题、代码修复、代码审查、文件问答——这些本质是系统提示预设，不是可加载/可安装的插件机制。
  2. MCP server 才是 Agent 真正的扩展/插件机制（见”工具体系”一节）：用户通过 “MCP Configuration” UI 或手改 user_mcp_config.json 添加第三方 MCP server；有 “Templates” 标签暗示存在一个精选的现成 MCP server 配置库（该库内容未观察到，大概率是运行时从智谱后端拉取，非随包分发）。
  • 未发现独立的”skill 文件”格式（不同于某些其他 harness 中基于 markdown 目录的 skill 机制）。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

未发现证据 / 官方未披露。 客户端未见轨迹回放、基于使用反馈的强化学习、或 eval 门控的自我纠错机制。对 survey/feedback/rating/thumbsUp 类字符串 grep，只找到一个通用的 feedback 扩展消息类型常量（extension.onClickToolbarItem 附近），以及旧版（2023，v1.1.2）插件的一次性 NPS 式”Survey”弹窗（Codegeex.Survey 设置，微信/QQ 外部问卷链接）——这是用户满意度调研，不是模型/agent 自我改进闭环。旧版 Codegeex.Privacy 设置（“Accept sharing the generated code only for research purposes to make CodeGeeX better”）是最接近数据飞轮/自我改进披露的东西——opt-in 上传生成代码用于（大概率离线、人工侧）模型改进，不是产品内自动 eval 驱动的纠错循环；而当前版本代码库索引的同意文案对该特定功能明确说的是相反的话（“不用于模型训练”）——两个功能的数据使用政策并不一致。结论：该维度未实现/未披露。

可观测性（日志 / trace 格式）

  • 本地 Python agent 有常规的三路滚动文件日志配置（dist/agent/log.yaml，明文 YAML，标准 logging.config.dictConfig schema）：
    • my_logger → 控制台（colorlog 按级别上色）+ logs/info/run.log（INFO 及以上）+ logs/error/errors.log（ERROR 及以上），均为 TimedRotatingFileHandler（午夜轮转，保留 3 份备份，UTF-8，delay=True）。
    • inference logger → 独立的 logs/inference/run.log 流（INFO），propagate: no —— 模型调用/推理事件记录在独立文件，与常规应用日志解耦。
    • uvicorn.error logger 仅路由到控制台。
    • 格式：[%(levelname)s] %(asctime)s - %(filename)s:%(lineno)d - %(message)s（纯文本）或带 ANSI 颜色（控制台）。
  • OpenTelemetry 脚手架存在但看起来是休眠/默认状态：dist/extension.js 中有一整块 OTEL_EXPORTER_OTLP_*/OTEL_EXPORTER_ZIPKIN_ENDPOINT/OTEL_PROPAGATORS:["tracecontext","baggage"]/OTEL_SERVICE_NAME 环境变量默认值。除一个占位符 http://localhost:9411/api/v2/spans（Zipkin 本地默认端点）外所有 endpoint 值均为空字符串——这更像是传递依赖带入的默认 OTEL SDK 环境变量脚手架（很可能是 mcp Python 包或某个 npm OTEL 依赖间接引入的），而非智谱主动配置、正在运营的 trace 采集管线。客户端侧未发现 trace 上传到智谱后端的证据。
  • 未发现除明文 history.json 聊天历史缓存（见”记忆”一节）之外的专用”轨迹导出”或会话回放文件格式。

安全与权限（审批门、密钥管理）

  • 逐工具调用人工审批是主要安全门（见”工具体系”一节：Accept/Reject/Keep Changes/Skip/Stop/Cancel 控件，“Please confirm whether to execute this command/tool” 提示）。未发现可配置的命令白/黑名单，或”自动批准安全命令”策略开关。
  • 密钥/会话安全：extension.js 中一个 mcp_client 相关的 session 类含有 rasPublicKey、aesKey、encryptedAESKey 字段，暗示存在RSA 包裹 AES 的密钥交换来保护某条信道（可能是本地 extension↔agent-server 的 localhost HTTP 流量，或 extension↔智谱云 API 鉴权）——从压缩 JS 无法完全还原确切协议细节，但字段名是明确的非对称密钥交换+对称加密模式证据。
  • context.secrets（VS Code 内置 SecretStorage API）被用于存储服务器配置/鉴权 token（this.context.secrets.get(c) 调用为 Ext.Agent/Ext.PythonMirrors 远程配置值取值）——即凭证/配置不是明文存在 globalState 里。
  • 远程熔断开关/功能开关：Ext.Agent 是服务端下发的配置值（.status），客户端据此决定是否 this.init()（启动 agent）或 this.stopAgent()——智谱后端可以在不发客户端更新的情况下远程禁用 agent 功能。类似地 Ext.PythonMirrors 让后端下发镜像源 URL（对中国网络可靠性有用，例如把 indexUrl 默认指到 https://pypi.tuna.tsinghua.edu.cn/simple）。
  • License/鉴权门控：存在 CheckLicense、GetLicenseInfo、OnLicenseChange、AuthCodebase 消息类型——代码库索引（@repo/@workspace）以及可能的 agent 模式访问都绑定登录/license 状态（2023 版仓库的 Codegeex.License 设置在概念上仍然存在；命令列表包含 codegeex.login）。
  • 工作区文件类型门控：whitelist 字段（由服务端配置 key Ext.WorkspaceValidLang 填充）限制哪些文件扩展名会被索引/处理——这是内容范围过滤，不是安全/执行权限门。

沙箱与执行隔离

  • executeCommand/终端工具运行在用户自己机器上真实的、无沙箱的 VS Code 集成终端里——dist/extension.js 中直接确认： 
    class Ia { static async createTerminal(A) {
  const t = n.window.createTerminal({cwd:A, name:"CodeGeeX", iconPath:...});
  ... return new ra(id, pid, t); } }
    （n.window.createTerminal 就是字面意义的 VS Code API vscode.window.createTerminal。）这个工具没有远程沙箱、没有容器、没有虚拟机——唯一的安全层是逐命令人工审批提示（见”工具体系”/“安全与权限”）。这与那些在隔离远程/容器化沙箱中执行的 harness 有本质不同的安全姿态。
  • 本地 Python 运行时隔离：agent 后端本身运行在首次使用时创建的 mamba/conda 管理的虚拟环境内（envName:"codegeex-agent"、venvPath:"venv"、mambaConfigTemplateFilename:"env.yml"，生命周期事件 CREATE_MAMBA_ENV）——这隔离的是agent 自身 Python 依赖与用户系统 Python 的冲突，并不沙箱化 agent 工具运行起来后能对文件系统/网络做什么。
  • VSIX 中为至少一个平台内置了预构建 venv tarball：venv/codegeex-agent-linux-arm64.tar.gz——说明会为部分平台预打包 Python 环境以跳过 mamba 求解步骤，其余情况回退到 create_mamba_env/install_requirements（读 agent_requirements.txt）。
  • “Code Interpreter”/数据分析工具箱功能存在独立、真正沙箱化的子系统——但这只在参考模型仓库（THUDM/CodeGeeX4/interpreter_demo/）中有文档，并非确认的生产实现。该参考设计（SANDBOX.md）指定了一个小型 HTTP API（GET / ping、POST /execute 带 {code, timeout_secs}、POST/GET /files/upload|download），前端对接看起来是一个 Jupyter/IPython kernel（响应事件包括 stream stdout/stderr、display_data 带 MIME variants（含 image/png）、file 写入、error 带 ename/evalue/traceback——正是 IPython 的 execute_result/display_data 消息形状），配套 Dockerfile.sandbox（用于运行不受信代码的容器镜像）与 sandbox.py/sandbox_tests.py。佐证这一事件 schema 在生产 agent 中确实存在：webview bundle 的 markdown 渲染代码专门 special-case 了 JSON.parse(t).metadata.interpreter.variants["image/png"]——即随包发布的 webview UI 明确知道如何渲染这种确切的 interpreter.variants 图片数据形状，强烈暗示生产环境的”Analyze Webpage”/数据分析工具路径复用了这套 kernel 式沙箱事件协议，尽管确切的生产沙箱后端（本地子进程 vs. 容器 vs. 远程服务）无法从加密的 Python 中确认。
  • ipykernel~=6.29.5 和 ipython~=8.31.0 是 agent 后端的直接依赖（agent_requirements.txt），这是Code Interpreter/数据分析工具运行真实内嵌 Jupyter/IPython kernel（在同一 mamba 环境内进程内运行或作为本地子进程）而非远程代码执行服务的有力佐证。

与模型的协同设计

  • Harness 与模型围绕 ChatGLM/GLM 分词器家族专属的特殊聊天 token（<|system|>、<|user|>、<|assistant|>）协同设计——CodeGeeX4-ALL-9B 按 THUDM/CodeGeeX4 README 明确说明是”continually trained on GLM-4-9B”，harness 的系统提示组装（见”Prompt 设计”）直接围绕这一格式构建，而非通用的 OpenAI 风格 messages 数组（不过 harness 大概率也会与智谱托管 API 对话，后者可能接受 messages 风格外壳并在服务端转换——客户端未能确认）。
  • Infilling / FIM（中间填充）是一等公开文档化的 harness 特性：官方 guides/Infilling_guideline.md 记录了专门用于 VS Code 插件代码补全的跨文件/全仓库填充提示格式（区别于 chat 格式）——即补全与聊天是针对同一模型家族的两套不同提示体制，各有专属指南。（该文件已存在于 model-repo/guides/，具体 FIM 特殊 token 排布未在笔记中逐字引用，需要时可直接读取。）
  • 128K 长上下文是主打的协同设计特性：codegeex4-all-9b 主打 128K 序列长度，专门用于支持全仓库上下文（仓库级问答、@workspace/@repo RAG 增强提示，以及模型卡上报告 Python 在 128K 下 100% 检索准确率的”Code Needle-in-a-Haystack”（NIAH）基准）——即记忆/上下文功能集（见”记忆”一节）是针对这一具体模型能力显式设计的，而非套在任意长上下文模型上的通用 RAG 组件。
  • 解码参数协同设计：旧版插件的配置 schema（Codegeex.DecodingStrategies.temp/topp/topk）把模型专属的采样旋钮直接暴露为用户可见的 VS Code 设置项，且模型仓库的 vLLM 用法示例中硬编码了 stop-token IDs（151329, 151336, 151338）——这些是 GLM 分词器专属的特殊 token ID，也是 harness 与该特定模型家族紧密耦合（而非模型无关设计）的又一佐证。

轨迹利用（session/trajectory 是否反哺训练/评测）

信号混合/矛盾，且都对用户做了明确披露，但分属两个不同功能：

  • 旧版（2023）插件的 Codegeex.Privacy 设置：“Accept sharing the generated code only for research purposes to make CodeGeeX better”——即基础补全功能历史上曾明确 opt-in 收集数据用于模型改进。
  • 当前版本（2.27.6）@repo/@workspace 代码库索引同意弹窗对该特定功能明确说的是相反的话：“will only be used to provide contextual information for your Q&A and completions, and will not be used for model training.”
  • 未找到任何专门覆盖 agent 模式工具调用轨迹的披露（无论 opt-in 或 opt-out）——即 Agent 模式下的工具调用/审批/编辑序列是否会被回传给智谱用于评测或训练。鉴于本地 history.json 是纯客户端本地文件，且在可读的 JS 中未找到针对它的遥测上传代码，没有找到证据支持或反对——记为未找到/不确定，而非明确的否定结论。
  • 结论：明文补全功能历史上部分实现且已披露（opt-in）；仓库索引 RAG 功能明确声明不用于训练；agent/工具调用轨迹的利用情况无法确定（服务端加密 + 客户端无上传证据）。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

  1. 工具执行完全无沙箱：executeCommand 直接落在用户本机真实 VS Code 集成终端（vscode.window.createTerminal），没有容器/VM 隔离，安全性单纯依赖逐命令人工审批——这与许多把执行放进远程/容器沙箱的 harness（如带独立 sandbox 服务的产品）形成鲜明对比。
  2. harness 自行安装并托管本地 Python agent 运行时：首次使用会在用户机器上跑 create_mamba_env → install_requirements → setup_mcp_tools → start_agent 的完整 bootstrap 流程，是一个”厂商在客户端本机自建 mini-PaaS”式设计，不同于纯粹调远程托管 agent API 的 harness。
  3. 工具协议是真实、官方的 MCP SDK（mcp>=1.6.0）而非自研协议套壳，且产品内 UI 明确以 “MCP(Model Context Protocol)” 向最终用户解释这一概念，用户自定义 MCP server 的门槛（编辑 user_mcp_config.json + 图形化 “MCP Configuration” 面板）与主流国际 harness 一致。 （其余维度的加密黑盒程度——尤其 agent 循环推理逻辑、system_prompt 动态组装、tool_finder 路由算法——是本次调研遇到的最大限制，跨 harness 对比时需注明”闭源+加密，仅文件名级证据”。）

原始源码定位

  • repo: 无公开当前源码。历史参考：
    • 模型发布仓库 https://github.com/THUDM/CodeGeeX4（demo/guides，非 harness）
    • 旧版插件源码仓库 https://github.com/CodeGeeX/codegeex-vscode-extension（2023 年停更，pre-agent）
    • 当前生产 harness 私有子模块（不可公开访问）：https://dev.aminer.cn/codegeex/codegeex-extension-siderbar.git、.../codegeex-extension-welcome.git、.../project-map.git、.../codegeex-mcp.git
  • commit/version analyzed:
    • THUDM/CodeGeeX4 @ 480f792bf9a57cfa8ccad84ea4366badab99bee3（depth-1 clone, main 分支 HEAD）
    • CodeGeeX/codegeex-vscode-extension @ 3bbc5305bae91928152eb76ef41c4b822edb3c56（tag 1.1.2，2023-01-29）
    • 当前生产 harness：VS Code Marketplace aminer.codegeex v2.27.6（published 2025-09-01T09:01:40.14Z），agent 后端内部版本号 1.3.11（configs/state_config.json）——直接从 Marketplace CDN 下载 VSIX 解压分析，这是本 dossier 的主要证据来源
  • 关键文件列表（相对路径，均相对各自证据目录）：
    • vsix-2.27.6/package.json — 当前版本清单（57 条命令，完整配置 schema）
    • vsix-2.27.6/mcp_config.json — 内置 MCP server 注册表（3 servers）
    • vsix-2.27.6/.gitmodules — 暴露 4 个私有 GitLab 子模块
    • vsix-2.27.6/state_config.json — agent 后端版本号
    • vsix-2.27.6/log.yaml — Python 日志配置
    • vsix-2.27.6/agent_requirements.txt — agent 后端 pip 依赖（fastapi/uvicorn/mcp/ipykernel/ipython 等）
    • vsix-2.27.6/agent-python-file-tree.txt — dist/agent 下全部 .py 文件相对路径清单（均 Pyarmor 加密，仅文件名可用）
    • vsix-2.27.6/extracted-evidence-strings.md — 从 dist/extension.js 与 webview-ui/dist/assets/index.js 提取的关键字符串（工具注册表、agent UI 文案、审批门文案、MCP UI 文案、@-mention providers、TerminalService.createTerminal、agent bootstrap 生命周期）
    • model-repo/guides/System_prompt_guideline.md — 官方系统提示模板（9 个模式全文）
    • model-repo/guides/Infilling_guideline.md、Repository_tasks_guideline.md、Local_mode_guideline.md
    • model-repo/interpreter_demo/（含 SANDBOX.md、Dockerfile.sandbox、sandbox.py、app.py）— 官方参考 Code Interpreter 沙箱设计
    • model-repo/function_call_demo/main.py — 参考 function-calling 循环
    • model-repo/repodemo/（run.py、prompts/base_prompt.py、utils/tools.py、utils/bingsearch.py）— 参考仓库级 ReAct agent demo
    • vscode-extension-repo-2023/package.json、src/ — 2023 旧版清单与源码（对照基线，证明当时无 chat/agent）

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/zhipu-codegeex/ 下：

  • NOTES.md — 本次调研的完整逐维度笔记（含所有原文引用出处）
  • model-repo/ — THUDM/CodeGeeX4 仓库克隆内容（README、guides/、interpreter_demo/、function_call_demo/、repodemo/）
  • vscode-extension-repo-2023/ — 2023 年旧版公开插件源码（package.json、src/）
  • vsix-2.27.6/ — 当前生产 VSIX（v2.27.6）解压后保留的证据文件：package.json、CHANGELOG.md、bundle.l10n.json、mcp_config.json、state_config.json、log.yaml、agent_requirements.txt、.gitmodules、agent-python-file-tree.txt、extracted-evidence-strings.md

未纳入存档但已就地检视：dist/extension.js（1.84MB 压缩后）、webview-ui/dist/assets/index.js（4.69MB，含 Monaco/CodeMirror 语法高亮关键词字典，grep 噪音较大）、venv/codegeex-agent-linux-arm64.tar.gz（预构建 venv）、wasm/（tree-sitter parser，推测用于补全的代码块边界检测）。

后续可跟进方向（未做，超出本轮范围）：JetBrains 插件版本（plugins.jetbrains.com/plugin/20587-codegeex）未单独下载分析；若要读到 agent 循环/tool_finder 真实逻辑，需要 Pyarmor 动态脱壳（sys.settrace 或 Pyarmor-aware unpacker）方案，属于另一轮工作。

关系图谱

反向链接