1. 当自改进智能体开始“自己改自己”Key 通道先要稳住Darwin Gödel Machine达尔文·哥德尔机器简称 DGM是一类让编码智能体通过修改自身代码库来持续变强的系统。它把“自我修改”和“下游任务评估”交替执行从智能体存档里挑一个父代让它读自己的失败日志、提出改进点、改自己的代码生成子代再拿编码基准测一遍能保留基本编辑能力的就进存档。适合谁适合正在做 Self-Improving Agents、Open-Ended Evolution 实验或者想把多模型调用统一到一个 Key/API 通道的开发者。我关注 DGM 落地时踩到的第一个坑其实不在算法而在“调用通道”。DGM 一次完整运行动辄几十次迭代每次迭代里父代诊断、子代生成、基准评估都要打模型接口。如果每个环节各写一套 base_url、各配一个 Key日志里根本分不清哪次请求属于自我修改、哪次属于评估排查起来非常痛苦。所以这篇给出一份可复制的config.toml骨架把模型调用统一收敛到 TaoToken 的 API 通道再附上验证动作启动后检查自改进循环是否正常调用 API、日志里确认请求通道生效。TaoToken 在这里的角色是统一 Key/API 通道官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口 https://taotoken.net/api 。下面所有配置都围绕“一个通道、多模型、可追溯”来写。2. 前置准备把 TaoToken 通道接进 DGM 的调用层DGM 的代码库通常把模型调用封装在一个 client 里父代诊断、子代生成、评估打分都走这个 client。我们要做的不是改算法而是把 client 的 base_url 和 api_key 指向 TaoToken让所有请求经过同一通道。先拿 Key。打开 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 创建一个项目级 Key。建议按用途分 Key一个给“自我修改”阶段一个给“基准评估”阶段这样日志里能直接区分两类流量。创建后复制保存后面写进config.toml。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面说明了兼容的请求格式。DGM 大多用 OpenAI 兼容的 chat completions 接口所以 base_url 填https://taotoken.net/api即可路径拼接交给 SDK。这里有个容易忽略的点DGM 的父代诊断模型和子代生成模型可能不是同一个。比如诊断用推理强的模型生成用编码强的模型。TaoToken 通道支持在请求里指定不同 model 字段所以config.toml里要留出“按角色分配模型”的位置而不是全局写死一个模型名。3. 可复制的 config.toml 骨架下面这份骨架按 DGM 的三个调用角色分区self_modify自我修改、evaluate基准评估、diagnose失败日志诊断。每个角色独立配置模型和 Key 别名但都指向同一个 TaoToken 通道。# config.toml —— Darwin Gödel Machine 调用通道骨架 [channel] # 统一 API 通道所有角色共用 base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY # 从环境变量读取不硬编码 timeout_seconds 120 max_retries 3 [channel.headers] # 便于在服务端日志里区分 DGM 流量 X-Client dgm-self-improving-agent [roles.self_modify] # 父代改自己代码库时使用 model claude-3-5-sonnet temperature 0.2 max_tokens 8192 api_key_env TAOTOKEN_API_KEY_MODIFY [roles.diagnose] # 分析失败评估日志、提出改进建议 model o3-mini temperature 0.0 max_tokens 4096 api_key_env TAOTOKEN_API_KEY_DIAGNOSE [roles.evaluate] # 基准评估阶段跑 SWE-bench / Polyglot 子集 model claude-3-5-sonnet temperature 0.0 max_tokens 4096 api_key_env TAOTOKEN_API_KEY_EVAL [archive] # 智能体存档开放式探索的核心 path ./dgm_archive keep_all true # 保留所有具备编辑能力的智能体 select_by [score, novelty] [loop] max_iterations 80 parallel_workers 2 # SWE-bench 建议 2Polyglot 可到 4 log_dir ./logs/dgm log_request_channel true # 关键日志记录每次请求走的通道几个参数说明。api_key_env全部走环境变量避免 Key 进版本库。log_request_channel true是验证通道生效的关键开关它会让 client 在每次请求后记录 base_url 和角色名。keep_all true对应 DGM 的开放式探索——所有保留编辑能力的智能体都进存档哪怕当前分数不高因为它可能是未来的“垫脚石”。环境变量这样设置export TAOTOKEN_API_KEY你的项目级Key export TAOTOKEN_API_KEY_MODIFY自我修改专用Key export TAOTOKEN_API_KEY_DIAGNOSE诊断专用Key export TAOTOKEN_API_KEY_EVAL评估专用Key如果你只想用一个 Key 跑通把三个api_key_env都指向TAOTOKEN_API_KEY即可先验证链路再按角色拆分。4. 验证请求确认自改进循环真的走了 TaoToken 通道配置写完先别急着跑 80 次迭代。用一个小循环验证通道。下面这段 Python 模拟 DGM 的一次“诊断→修改→评估”调用确认三个角色都能通。import os import toml from openai import OpenAI cfg toml.load(config.toml) channel cfg[channel] def make_client(role): role_cfg cfg[roles][role] return OpenAI( base_urlchannel[base_url], api_keyos.environ[role_cfg[api_key_env]], ), role_cfg def call(role, prompt): client, role_cfg make_client(role) resp client.chat.completions.create( modelrole_cfg[model], messages[{role: user, content: prompt}], temperaturerole_cfg[temperature], max_tokensrole_cfg[max_tokens], ) return resp.choices[0].message.content # 模拟 DGM 一次迭代的三个调用 diag call(diagnose, 分析这段失败日志给出一个改进点...) mod call(self_modify, f基于建议实现改进{diag}) score call(evaluate, 评估这个补丁是否通过测试...) print(diagnose ok:, diag[:60]) print(self_modify ok:, mod[:60]) print(evaluate ok:, score[:60])跑通后去./logs/dgm看日志。你应该能看到类似这样的记录[2025-xx-xx 10:12:03] rolediagnose channelhttps://taotoken.net/api modelo3-mini status200 [2025-xx-xx 10:12:11] roleself_modify channelhttps://taotoken.net/api modelclaude-3-5-sonnet status200 [2025-xx-xx 10:12:19] roleevaluate channelhttps://taotoken.net/api modelclaude-3-5-sonnet status200如果channel字段显示的是https://taotoken.net/api说明请求通道生效。如果显示的是别的地址检查 client 初始化时有没有被代码里硬编码的 base_url 覆盖。DGM 有些实现会在 client 内部再写一层默认地址优先级高于config.toml这是最常见的“配置没生效”原因。再验证自改进循环本身。启动一次小规模运行python -m dgm.run --config config.toml --iterations 3 --benchmark swe-bench-mini观察日志里是否出现完整的“选择父代→诊断→自我修改→评估→入存档”链路。正常输出会像[iter 1] selected parentnode_0 score0.20 [iter 1] diagnose done, proposaladd_line_level_edit [iter 1] self_modify done, new_agentnode_1 [iter 1] evaluate done, score0.24, archivedtruearchivedtrue表示子代保留了编辑能力进了存档。如果连续几次都是archivedfalse说明自我修改把编辑工具改坏了这时候要回看self_modify角色的输出通常是提示词里没强调“必须保留文件编辑能力”。5. 本篇常见错排查报错一401 Unauthorized但 Key 明明是对的。先确认环境变量有没有被 shell 会话继承。export只在当前终端有效如果你用nohup或 systemd 启动要在对应配置里重新声明。另一个原因是 Key 别名写错config.toml里api_key_env写的是变量名不是 Key 本身别把 Key 直接填进去。报错二请求超时尤其self_modify角色。自我修改阶段要读整个代码库、生成大段补丁max_tokens给太小会截断给太大又容易超时。建议timeout_seconds设 120 以上max_retries设 3。如果还是超时把self_modify的模型换成响应更快的或者把代码库分块喂给模型。报错三日志里channel字段为空。说明 client 没走config.toml的通道配置。检查 DGM 代码里创建 client 的地方是不是有OpenAI(base_url...)这样的硬编码。把它改成从config.toml读取。这是接入统一通道时最高频的问题。报错四评估分数一直不涨存档里全是低分节点。这不一定是通道问题但通道配置会影响它。如果evaluate角色和self_modify角色用了同一个 Key 但不同模型确认模型名没写错。模型名写错时接口可能返回一个默认模型的结果分数自然不对。另外检查keep_all true是否生效如果存档只留最高分开放式探索就退化成爬山DGM 论文里明确说这会变差。报错五并行迭代时日志串行混乱。parallel_workers大于 1 时多个迭代同时写日志。给每个 worker 单独一个log_dir子目录或者在日志行里加worker_id。TaoToken 通道本身支持并发问题一般出在本地日志写入。6. 把通道固定下来再让智能体去进化DGM 这类自改进系统的魅力在于它会把“改进能力”本身也当成可优化的对象。但前提是每次调用的输入输出都可追溯否则你根本不知道某一代变强是因为改对了工具还是因为某次请求悄悄换了模型。把 Key/API 通道统一到 TaoToken 之后config.toml里的角色分区让自我修改、诊断、评估三类流量各走各的 Key日志里一眼能看出哪次请求属于哪个阶段。如果你接下来要长期跑编码类 Agent或者想让多个自改进循环共享同一套模型通道可以看看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合持续性的编码调用场景。想先手动验证某个模型在诊断任务上的表现用模型对话 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 直接试。接入细节和参数对照都在接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里配置卡住时优先翻它。