1. 为什么我要把 Harness Engineering 蒸馏成四个 SkillOpenAI 在 2 月发了一篇 Harness Engineering 的文章讲他们怎么用 Codex 搭一个让 Agent 持续工作的执行环境。核心数据很扎眼3 个工程师、5 个月、100 万行代码、零手写、每人每天 3.5 个 PR。我第一遍读完的感受不是好厉害而是这不就是我一直想做的那个东西吗。我让 Agent 跑长任务一直有几个固定痛点Context 重置之后不知道上一轮干了什么跑到一半觉得差不多了就自己停遇到模糊的地方卡住等我确认。OpenAI 那篇文章把这些问题讲得很清楚也给了他们的解法。但他们的工具链是 Codex 云端加自研基础设施我是本地环境直接照搬不现实。所以真正的问题变成了怎么把文章里的方法论蒸馏成我能用的东西。我读技术文章习惯把内容分三类——直接可用的机制、思路可借鉴但实现要改的、他们能做但我现在不考虑的。这篇文章就是这套蒸馏过程的完整复盘包括四个 Skill 的职责划分、Codex auth.json 改到 TaoToken 统一通道的配置片段以及一次 25 小时 Agent 长跑的日志验证动作。如果你也在本地跑 Codex 或 Claude Code 这类编码 Agent想让它们从跑十分钟就停变成能连续跑一整天这篇的配置和排障步骤可以直接跟做。适合有后端基础、已经在用 Agent 写代码、但被长任务稳定性卡住的人。2. 蒸馏 Harness Engineering 的四个 Skill 与职责划分蒸馏完之后我发现要解决的问题自然分成了几层让 Agent 能持续跑、跑断了能恢复这是执行引擎问题让业务流测试有证据、判定来自不变式而不是脚本退出码这是验证问题让架构规则机械化执行、不依赖 Agent 自觉这是约束问题让 Prompt 写完 Agent 就不会停这是运行策略问题。对应下来就是四个 Skill。2.1 四个 Skill 的职责划分表Skill 名称解决的问题核心机制关键产物harness持久执行与状态恢复进度文件即上下文harness-tasks.json、harness-progress.txt、git logclosed-loop-testing业务流验证有证据判定来自业务不变式verdict.json、请求响应记录、数据库快照architecture-guardrails架构规则机械执行结构测试 ratchet 策略allowlist、CI 结构测试harness-marathon运行策略不中断三定律 Doom Loop 检测依赖清单、编辑次数告警harness 是执行引擎。OpenAI 把 execution plans 和 decision logs 存在仓库里Context 重置后 Agent 读这些文件就能恢复状态。我照搬了这个思路用 harness-tasks.json 存任务拆解、harness-progress.txt 存操作日志再加一个 git log三件事一起读10 秒内恢复会话。AGENTS.md 当目录不当百科全书控制在 100 行左右真正的知识放 docs/ 里。他们试过一个大 AGENTS.md失败了原因我都踩过文件太大挤占有效 Context规则写太多等于没规则一旦过期 Agent 没法分辨哪些还是真的。closed-loop-testing 是验证层。OpenAI 的可观测性方案是每个 git worktree 配独立的 Victoria Logs Metrics TracesAgent 用 LogQL/PromQL/TraceQL 查。思路很好但我的场景偏业务流测试不是性能调优所以换成了证据包概念每个业务流测试完必须产出 verdict.json、请求响应记录、数据库快照、过滤好的日志判定来自业务不变式不来自脚本跑完了。业务流测试分三阶段V1 测内部可控路径V2 加入外部回调V3 产出完整证据包。architecture-guardrails 是约束层。OpenAI 用自定义 linter 加结构测试强制执行分层约束lint 错误信息本身包含修复指引。这个设计很聪明——Agent 违规时报错报错信息直接告诉它怎么改不需要再去找文档。我把它编码成结构测试在 CI 里跑加上 ratchet 策略遗留违规加到 allowlist新代码必须通过慢慢蚕食存量问题。harness-marathon 是运行策略层OpenAI 文章里没有对应东西是我加的。它本质是一套分析框架Agent 停下来只有三个原因——工作耗尽了、遇到不确定的地方卡住了、Context 退化了。把这三个原因逐个干掉Agent 就能跑很久。三定律里 Law 2Zero decision points最容易被忽略提前把所有外部依赖写进 Prompt说起来简单但每次 Agent 中途停了回头查基本都是漏写了某个依赖。3. 把 Codex auth.json 改到 TaoToken 统一通道四个 Skill 要跑起来Agent 得先能稳定调用模型。我这边 Codex 负责开发写 PRClaude Code 负责 review两边如果各用各的 Key长跑时切换和额度管理都很乱。所以我把 Codex 的 auth.json 改到 TaoToken 统一通道一个 Key 走所有模型调用。TaoToken 在这里的角色是统一 API 通道官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它不替代编辑器也不替代 Codex 本身只是把模型调用的 Base URL 和 Key 收敛到一处方便长跑时统一管理。3.1 Codex auth.json 配置片段Codex 的 auth.json 一般在用户目录下的 .codex 文件夹里。改之前先备份一份然后按下面结构写。三件套是 Base URL、Key、Model ID缺一不可。{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api, model: gpt-5-codex, provider: { name: taotoken, baseURL: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥 } }如果你用的是 Codex CLI 的 config.toml对应写法是这样[model_providers.taotoken] name taotoken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.default] model gpt-5-codex model_provider taotokenKey 的获取在控制台的 API Keys 页面地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。生成后复制到上面配置里注意不要提交到 git 仓库用环境变量或本地文件隔离。3.2 Claude Code 侧的 settings 片段Claude Code 做 review走的是 Anthropic 兼容通道。settings.json 里这样配{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥, ANTHROPIC_MODEL: claude-sonnet-4-5 } }这样 Codex 和 Claude Code 共用同一个 Key 和 Base URL长跑时额度、日志、切换都在一处。如果你用 CC Switch 管理多套配置把上面这段作为一个 profile 存进去切换时不用手改文件。Cline MCP 的场景同理Base URL 填 https://taotoken.net/api Key 填同一个Model ID 按你实际用的填。4. 验证请求与 25 小时长跑的日志动作配置写完不能直接开跑先做一次最小验证请求确认通道通了再上长任务。4.1 最小验证请求用 curl 打一次模型对话接口确认返回正常curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: gpt-5-codex, messages: [{role: user, content: reply with ok}] }返回里能看到 choices 数组和正常内容说明 Base URL、Key、Model ID 三件套都对。如果这一步就报错先别往下走去第 5 节对照排查。想先在网页里确认模型可用可以打开模型对话页面 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 手动发一条消息排除是本地配置问题还是通道问题。4.2 25 小时长跑的日志验证动作那次 25 小时的长跑是一个比较大的 Go 服务重构任务任务拆了 40 多个。跑之前我在 harness-tasks.json 里把每个子任务和依赖写清楚harness-progress.txt 初始化为空然后启动。长跑期间我做了几个固定的日志验证动作。第一个动作是每 2 小时检查一次 harness-progress.txt 的最后 20 行确认 Agent 在推进而不是绕圈。如果发现同一个文件被反复编辑就去看 Doom Loop 计数。我在 harness 里加了机制同一个文件编辑超过 6 次报警超过 12 次强提醒。实测触发频率比我预想的高每次触发基本就是 Agent 在绕圈当前思路走不通需要人工介入换个方向。第二个动作是检查 git log 的提交节奏。正常推进时提交是均匀的如果连续两小时没有新提交要么是卡在某个依赖上要么是 Context 退化。这时候去看 harness-progress.txt 里最后一条记录通常能定位到卡点。第三个动作是验证 closed-loop-testing 的证据包。每个业务流测试完检查 verdict.json 是否存在、判定字段是否来自业务不变式。V1 阶段成功率接近 100%V2 如果外部服务挂了可以切 replay 模式不影响整体进度。以前我直接跑 E2E经常因为外部服务不稳定全挂得重来分阶段之后稳定很多。跑完 25 小时任务一次通过率大概 80%。剩下 20% 里一半是需要人介入的真实设计分歧一半是 Prompt 写得不够清楚导致的理解偏差。前者本来就该人来处理后者可以继续优化 Prompt。5. 本篇常见错误排查长跑接入过程中我踩过的坑基本集中在这几类报错对照着查能省不少时间。401 报错最常见。表现是请求返回 Unauthorized原因通常是 Key 没填对、Key 过期、或者 auth.json 里 Key 和 Base URL 不匹配。先确认 Key 是从控制台 API Keys 页面复制的完整字符串没有多余空格再确认 OPENAI_BASE_URL 和 provider.baseURL 都指向 https://taotoken.net/api 没有多写或少写路径。如果 Codex 和 Claude Code 共用 Key检查两边是不是都改了只改一边会出现一边通一边 401。local proxy failed 报错。这个通常是本地网络或代理配置干扰了请求。检查环境变量里有没有残留的 HTTP_PROXY、HTTPS_PROXY 指向本地端口有的话先清掉再试。另外确认 auth.json 里没有写死某个本地代理地址。这个报错和通道本身无关是本地环境问题。reading choices 报错。表现是请求发出去了但解析响应时读不到 choices 字段。原因一般是 Model ID 写错了或者请求体格式不对。确认 model 字段填的是通道支持的模型名请求体是标准的 messages 数组结构。如果用的是 config.toml检查 model 和 model_provider 是否对应。OAuth 相关报错。Codex 有些版本会走 OAuth 登录流程如果你已经改成 Key 认证残留的 OAuth 配置会冲突。检查 .codex 目录下有没有旧的凭据文件清掉后重新用 auth.json 的 Key 方式启动。CC Switch 用户注意 profile 切换后要重启 Codex 进程否则读的还是旧配置。还有一个不报错但很坑的情况配置全对但 Agent 跑一会儿就停。这基本不是通道问题是 harness-marathon 的 Law 2 没做到位Prompt 里漏写了某个外部依赖。回头查 harness-progress.txt 最后一条记录通常能看到 Agent 停在等某个路径或某个 Key 上。把依赖补进 Prompt 再跑。6. 长期编码与 Agent 长跑的接入建议如果你打算把这套东西长期跑起来几个实际建议。Codex 负责开发写 PR、Claude Code 负责 review 的组合比我预期好两个 Agent 训练方式不同review 盲区不重叠PR 质量明显上来。这跟 OpenAI 说的 agent-to-agent review 是同一个思路只是用两个不同模型实现。长期跑编码任务和 Agent 的话Coding Plan 比按量调用更划算地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配置细节和模型列表都在里面。Claude Code 的接入说明单独有一页 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 走 Anthropic 兼容通道的话照着配就行。蒸馏一篇技术文章提炼成可用工具核心是问三个问题这个做法解决的是什么问题不是他们做了什么而是为什么要这么做我的场景里这个问题存在吗有没有更简单的实现能解决同一个问题。不是所有机制都值得完整实现OpenAI 的 doc-gardening Agent 是个后台定期扫描修复文档的 Agent我现在的场景里结构测试加人工偶尔检查就够了没必要搭那个 Agent等不够用了再加。
从 OpenAI Harness Engineering 蒸馏出四个 Skill，Agent 跑了 25 小时：把 Codex auth.json 改到 TaoToken 的完整复盘
1. 为什么我要把 Harness Engineering 蒸馏成四个 SkillOpenAI 在 2 月发了一篇 Harness Engineering 的文章讲他们怎么用 Codex 搭一个让 Agent 持续工作的执行环境。核心数据很扎眼3 个工程师、5 个月、100 万行代码、零手写、每人每天 3.5 个 PR。我第一遍读完的感受不是好厉害而是这不就是我一直想做的那个东西吗。我让 Agent 跑长任务一直有几个固定痛点Context 重置之后不知道上一轮干了什么跑到一半觉得差不多了就自己停遇到模糊的地方卡住等我确认。OpenAI 那篇文章把这些问题讲得很清楚也给了他们的解法。但他们的工具链是 Codex 云端加自研基础设施我是本地环境直接照搬不现实。所以真正的问题变成了怎么把文章里的方法论蒸馏成我能用的东西。我读技术文章习惯把内容分三类——直接可用的机制、思路可借鉴但实现要改的、他们能做但我现在不考虑的。这篇文章就是这套蒸馏过程的完整复盘包括四个 Skill 的职责划分、Codex auth.json 改到 TaoToken 统一通道的配置片段以及一次 25 小时 Agent 长跑的日志验证动作。如果你也在本地跑 Codex 或 Claude Code 这类编码 Agent想让它们从跑十分钟就停变成能连续跑一整天这篇的配置和排障步骤可以直接跟做。适合有后端基础、已经在用 Agent 写代码、但被长任务稳定性卡住的人。2. 蒸馏 Harness Engineering 的四个 Skill 与职责划分蒸馏完之后我发现要解决的问题自然分成了几层让 Agent 能持续跑、跑断了能恢复这是执行引擎问题让业务流测试有证据、判定来自不变式而不是脚本退出码这是验证问题让架构规则机械化执行、不依赖 Agent 自觉这是约束问题让 Prompt 写完 Agent 就不会停这是运行策略问题。对应下来就是四个 Skill。2.1 四个 Skill 的职责划分表Skill 名称解决的问题核心机制关键产物harness持久执行与状态恢复进度文件即上下文harness-tasks.json、harness-progress.txt、git logclosed-loop-testing业务流验证有证据判定来自业务不变式verdict.json、请求响应记录、数据库快照architecture-guardrails架构规则机械执行结构测试 ratchet 策略allowlist、CI 结构测试harness-marathon运行策略不中断三定律 Doom Loop 检测依赖清单、编辑次数告警harness 是执行引擎。OpenAI 把 execution plans 和 decision logs 存在仓库里Context 重置后 Agent 读这些文件就能恢复状态。我照搬了这个思路用 harness-tasks.json 存任务拆解、harness-progress.txt 存操作日志再加一个 git log三件事一起读10 秒内恢复会话。AGENTS.md 当目录不当百科全书控制在 100 行左右真正的知识放 docs/ 里。他们试过一个大 AGENTS.md失败了原因我都踩过文件太大挤占有效 Context规则写太多等于没规则一旦过期 Agent 没法分辨哪些还是真的。closed-loop-testing 是验证层。OpenAI 的可观测性方案是每个 git worktree 配独立的 Victoria Logs Metrics TracesAgent 用 LogQL/PromQL/TraceQL 查。思路很好但我的场景偏业务流测试不是性能调优所以换成了证据包概念每个业务流测试完必须产出 verdict.json、请求响应记录、数据库快照、过滤好的日志判定来自业务不变式不来自脚本跑完了。业务流测试分三阶段V1 测内部可控路径V2 加入外部回调V3 产出完整证据包。architecture-guardrails 是约束层。OpenAI 用自定义 linter 加结构测试强制执行分层约束lint 错误信息本身包含修复指引。这个设计很聪明——Agent 违规时报错报错信息直接告诉它怎么改不需要再去找文档。我把它编码成结构测试在 CI 里跑加上 ratchet 策略遗留违规加到 allowlist新代码必须通过慢慢蚕食存量问题。harness-marathon 是运行策略层OpenAI 文章里没有对应东西是我加的。它本质是一套分析框架Agent 停下来只有三个原因——工作耗尽了、遇到不确定的地方卡住了、Context 退化了。把这三个原因逐个干掉Agent 就能跑很久。三定律里 Law 2Zero decision points最容易被忽略提前把所有外部依赖写进 Prompt说起来简单但每次 Agent 中途停了回头查基本都是漏写了某个依赖。3. 把 Codex auth.json 改到 TaoToken 统一通道四个 Skill 要跑起来Agent 得先能稳定调用模型。我这边 Codex 负责开发写 PRClaude Code 负责 review两边如果各用各的 Key长跑时切换和额度管理都很乱。所以我把 Codex 的 auth.json 改到 TaoToken 统一通道一个 Key 走所有模型调用。TaoToken 在这里的角色是统一 API 通道官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。它不替代编辑器也不替代 Codex 本身只是把模型调用的 Base URL 和 Key 收敛到一处方便长跑时统一管理。3.1 Codex auth.json 配置片段Codex 的 auth.json 一般在用户目录下的 .codex 文件夹里。改之前先备份一份然后按下面结构写。三件套是 Base URL、Key、Model ID缺一不可。{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api, model: gpt-5-codex, provider: { name: taotoken, baseURL: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥 } }如果你用的是 Codex CLI 的 config.toml对应写法是这样[model_providers.taotoken] name taotoken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [profiles.default] model gpt-5-codex model_provider taotokenKey 的获取在控制台的 API Keys 页面地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。生成后复制到上面配置里注意不要提交到 git 仓库用环境变量或本地文件隔离。3.2 Claude Code 侧的 settings 片段Claude Code 做 review走的是 Anthropic 兼容通道。settings.json 里这样配{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoToken密钥, ANTHROPIC_MODEL: claude-sonnet-4-5 } }这样 Codex 和 Claude Code 共用同一个 Key 和 Base URL长跑时额度、日志、切换都在一处。如果你用 CC Switch 管理多套配置把上面这段作为一个 profile 存进去切换时不用手改文件。Cline MCP 的场景同理Base URL 填 https://taotoken.net/api Key 填同一个Model ID 按你实际用的填。4. 验证请求与 25 小时长跑的日志动作配置写完不能直接开跑先做一次最小验证请求确认通道通了再上长任务。4.1 最小验证请求用 curl 打一次模型对话接口确认返回正常curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: gpt-5-codex, messages: [{role: user, content: reply with ok}] }返回里能看到 choices 数组和正常内容说明 Base URL、Key、Model ID 三件套都对。如果这一步就报错先别往下走去第 5 节对照排查。想先在网页里确认模型可用可以打开模型对话页面 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 手动发一条消息排除是本地配置问题还是通道问题。4.2 25 小时长跑的日志验证动作那次 25 小时的长跑是一个比较大的 Go 服务重构任务任务拆了 40 多个。跑之前我在 harness-tasks.json 里把每个子任务和依赖写清楚harness-progress.txt 初始化为空然后启动。长跑期间我做了几个固定的日志验证动作。第一个动作是每 2 小时检查一次 harness-progress.txt 的最后 20 行确认 Agent 在推进而不是绕圈。如果发现同一个文件被反复编辑就去看 Doom Loop 计数。我在 harness 里加了机制同一个文件编辑超过 6 次报警超过 12 次强提醒。实测触发频率比我预想的高每次触发基本就是 Agent 在绕圈当前思路走不通需要人工介入换个方向。第二个动作是检查 git log 的提交节奏。正常推进时提交是均匀的如果连续两小时没有新提交要么是卡在某个依赖上要么是 Context 退化。这时候去看 harness-progress.txt 里最后一条记录通常能定位到卡点。第三个动作是验证 closed-loop-testing 的证据包。每个业务流测试完检查 verdict.json 是否存在、判定字段是否来自业务不变式。V1 阶段成功率接近 100%V2 如果外部服务挂了可以切 replay 模式不影响整体进度。以前我直接跑 E2E经常因为外部服务不稳定全挂得重来分阶段之后稳定很多。跑完 25 小时任务一次通过率大概 80%。剩下 20% 里一半是需要人介入的真实设计分歧一半是 Prompt 写得不够清楚导致的理解偏差。前者本来就该人来处理后者可以继续优化 Prompt。5. 本篇常见错误排查长跑接入过程中我踩过的坑基本集中在这几类报错对照着查能省不少时间。401 报错最常见。表现是请求返回 Unauthorized原因通常是 Key 没填对、Key 过期、或者 auth.json 里 Key 和 Base URL 不匹配。先确认 Key 是从控制台 API Keys 页面复制的完整字符串没有多余空格再确认 OPENAI_BASE_URL 和 provider.baseURL 都指向 https://taotoken.net/api 没有多写或少写路径。如果 Codex 和 Claude Code 共用 Key检查两边是不是都改了只改一边会出现一边通一边 401。local proxy failed 报错。这个通常是本地网络或代理配置干扰了请求。检查环境变量里有没有残留的 HTTP_PROXY、HTTPS_PROXY 指向本地端口有的话先清掉再试。另外确认 auth.json 里没有写死某个本地代理地址。这个报错和通道本身无关是本地环境问题。reading choices 报错。表现是请求发出去了但解析响应时读不到 choices 字段。原因一般是 Model ID 写错了或者请求体格式不对。确认 model 字段填的是通道支持的模型名请求体是标准的 messages 数组结构。如果用的是 config.toml检查 model 和 model_provider 是否对应。OAuth 相关报错。Codex 有些版本会走 OAuth 登录流程如果你已经改成 Key 认证残留的 OAuth 配置会冲突。检查 .codex 目录下有没有旧的凭据文件清掉后重新用 auth.json 的 Key 方式启动。CC Switch 用户注意 profile 切换后要重启 Codex 进程否则读的还是旧配置。还有一个不报错但很坑的情况配置全对但 Agent 跑一会儿就停。这基本不是通道问题是 harness-marathon 的 Law 2 没做到位Prompt 里漏写了某个外部依赖。回头查 harness-progress.txt 最后一条记录通常能看到 Agent 停在等某个路径或某个 Key 上。把依赖补进 Prompt 再跑。6. 长期编码与 Agent 长跑的接入建议如果你打算把这套东西长期跑起来几个实际建议。Codex 负责开发写 PR、Claude Code 负责 review 的组合比我预期好两个 Agent 训练方式不同review 盲区不重叠PR 质量明显上来。这跟 OpenAI 说的 agent-to-agent review 是同一个思路只是用两个不同模型实现。长期跑编码任务和 Agent 的话Coding Plan 比按量调用更划算地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配置细节和模型列表都在里面。Claude Code 的接入说明单独有一页 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 走 Anthropic 兼容通道的话照着配就行。蒸馏一篇技术文章提炼成可用工具核心是问三个问题这个做法解决的是什么问题不是他们做了什么而是为什么要这么做我的场景里这个问题存在吗有没有更简单的实现能解决同一个问题。不是所有机制都值得完整实现OpenAI 的 doc-gardening Agent 是个后台定期扫描修复文档的 Agent我现在的场景里结构测试加人工偶尔检查就够了没必要搭那个 Agent等不够用了再加。
