我把“软件著作权”做成了一个 Agent Skill：Copyright Forge 接入 TaoToken 的配置升级实录

1. 为什么软著材料总在“编”而不是“证”

先说清楚 Copyright Forge 是什么：它是一个面向中国软件著作权登记材料准备的 Agent Skill，核心思路是 Evidence Driven，也就是证据驱动。它能做什么？扫描你的真实项目、识别技术栈与功能模块、建立功能到代码的证据映射、生成软件说明书与源程序材料、最后再切换成审核者角色复查一遍。适合谁？手里有已经写完的项目、准备申请软著、但完全不懂软著流程的开发者，尤其是第一次申请、面对一堆字段不知道从哪下手的同学。

我见过太多人把软著材料直接丢给大模型，结果 AI 为了让说明书“完整”，自动补上代码里根本没有的功能。项目里只有用户登录、文章管理、评论管理，说明书里却冒出智能内容推荐、用户行为分析、实时消息推送。听起来高级，但代码里找不到依据，这就是典型的“写得很好，但不真实”。软著材料不是营销文案，重要功能描述必须能回到真实项目找到证据。

Copyright Forge 的解法是把整个流程工程化：先调查项目，再建立证据，只询问代码无法判断的信息，确认后锁定统一事实源，生成材料，最后独立审核。它不是一个更长的提示词，而是一套可复用的专业工作方法。这篇就聚焦一件事：怎么把它接进 Codex、Claude Code、OpenCode，并用 TaoToken 作为统一模型通道，让 Skill 稳定触发。

2. 接入前的准备：TaoToken 统一 Key 与 Skill 安装

在配置 Agent 之前，先把两件事准备好：模型通道和 Skill 本体。

模型通道用 TaoToken。它的作用是给 Codex、Claude Code、OpenCode 这类工具提供统一的 API 入口，你只需要一个 Key，就能在不同 Agent 里复用同一套模型能力，不用每个工具单独折腾一遍鉴权。先到官网注册并进入控制台，在 API Keys 页面创建一个 Key，复制保存好，后面三个工具的配置都会用到它。

• 官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=
• API 地址：https://taotoken.net/api
• 创建 Key：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys

Skill 本体从 GitHub 拉取。Copyright Forge 目前对 Claude Code、Codex、OpenCode 都提供了安装方式，核心是把 skills/copyright-forge 目录放到对应 Agent 的 skills 路径下。以 Codex 为例，安装命令如下：

CF_SKILL_HOME="${CODEX_HOME:-$HOME/.codex}" mkdir -p "$CF_SKILL_HOME" git clone --depth 1 \ https://github.com/Rodert/copyright-forge-skill.git \ "$CF_SKILL_HOME/copyright-forge-repo" mkdir -p "$CF_SKILL_HOME/skills" ln -s \ ../copyright-forge-repo/skills/copyright-forge \ "$CF_SKILL_HOME/skills/copyright-forge"

装完重新开启一个 Codex 会话，进入你的代码项目目录，直接说“帮我给这个项目做软著”就能触发。Claude Code 和 OpenCode 的安装逻辑类似，区别只在 skills 目录位置，下面配置章节会分别给出。

注意：Skill 目录用软链接指向仓库，后续 Skill 自更新时只需要更新仓库，软链接不用动。如果你手动改过仓库里的文件，自更新会检测到本地修改并停止，不会覆盖你的改动。

3. 三套可复制的配置骨架

这一节是重点，直接给可复制的配置。三个工具的配置思路一致：把模型请求指向 TaoToken 的 API 地址，用同一个 Key 鉴权，再把 Skill 目录挂进去。

3.1 Codex 的 config.toml 骨架

Codex 的配置放在~/.codex/config.toml。下面这份骨架把模型通道指向 TaoToken，Key 通过环境变量注入，避免明文写死在文件里：

# ~/.codex/config.toml model = "claude-sonnet-4-5" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat" [skills] paths = ["~/.codex/skills"]

然后在 shell 里导出 Key：

export TAOTOKEN_API_KEY="sk-你的TaoToken密钥"

把上面这行写进~/.bashrc或~/.zshrc，新开终端就自动生效。wire_api用chat即可，base_url一定不要带末尾斜杠，否则部分客户端会拼出双斜杠导致 404。

3.2 Claude Code 的 settings.json 骨架

Claude Code 的配置放在~/.claude/settings.json。它用 JSON 描述环境变量和 Skill 路径：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_AUTH_TOKEN": "sk-你的TaoToken密钥", "ANTHROPIC_MODEL": "claude-sonnet-4-5" }, "skills": { "paths": [ "~/.claude/skills/copyright-forge" ] } }

Skill 安装到 Claude Code 的路径：

CF_SKILL_HOME="$HOME/.claude" mkdir -p "$CF_SKILL_HOME/skills" git clone --depth 1 \ https://github.com/Rodert/copyright-forge-skill.git \ "$CF_SKILL_HOME/copyright-forge-repo" ln -s \ ../copyright-forge-repo/skills/copyright-forge \ "$CF_SKILL_HOME/skills/copyright-forge"

3.3 OpenCode 的 config.toml 骨架

OpenCode 的配置放在~/.config/opencode/config.toml，结构上和 Codex 接近：

# ~/.config/opencode/config.toml model = "claude-sonnet-4-5" provider = "taotoken" [providers.taotoken] base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" [skills] paths = ["~/.config/opencode/skills"]

Skill 安装：

CF_SKILL_HOME="$HOME/.config/opencode" mkdir -p "$CF_SKILL_HOME/skills" git clone --depth 1 \ https://github.com/Rodert/copyright-forge-skill.git \ "$CF_SKILL_HOME/copyright-forge-repo" ln -s \ ../copyright-forge-repo/skills/copyright-forge \ "$CF_SKILL_HOME/skills/copyright-forge"

三个工具对照一下关键差异：

工具	配置文件	模型地址字段	Key 字段	Skill 路径
Codex	~/.codex/config.toml	base_url	env_key	~/.codex/skills
Claude Code	~/.claude/settings.json	ANTHROPIC_BASE_URL	ANTHROPIC_AUTH_TOKEN	~/.claude/skills
OpenCode	~/.config/opencode/config.toml	base_url	api_key_env	~/.config/opencode/skills

提示：三个工具可以共用同一个 TaoToken Key，配置里都通过环境变量读取，换 Key 时只改一处环境变量即可，不用逐个改配置文件。

4. 一次完整的调用验证

配置写完，必须验证 Skill 在 TaoToken 通道下能正常触发。验证分两步：先确认模型通道通，再确认 Skill 被识别。

第一步，验证 API 通道。用 curl 直接打一次 TaoToken 的接口，确认 Key 和地址没问题：

curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "claude-sonnet-4-5", "messages": [ {"role": "user", "content": "只回复两个字：通了"} ] }'

返回里能看到模型回复内容，说明通道正常。如果返回 401，是 Key 问题；返回 404，多半是 base_url 拼错或带了多余斜杠。

第二步，验证 Skill 触发。进入一个真实项目目录，启动 Agent，输入：

帮我给当前项目做软著。

正常情况下，Agent 不会一上来就问你软件名称、版本号、著作权人，而是先扫描项目：读 README、看目录结构、分析依赖文件、识别路由和 Controller、判断技术栈。这一步是 Copyright Forge 和普通提示词最大的区别——先调查，再提问。

扫描完成后，它会生成证据地图evidence-map.json，把识别到的功能和代码位置对应起来，比如：

{ "features": [ { "name": "用户登录", "evidence": [ "backend/controller/login.go", "backend/service/auth.go" ] }, { "name": "订单管理", "evidence": [ "backend/model/order.go", "backend/service/order.go" ] } ] }

接着它会推荐软件名称、版本、技术栈等信息，并只针对代码无法判断的现实事实提问，比如“这个软件主要是谁开发的，是你自己独立完成，还是和其他人/公司共同开发的”。你确认后，它会锁定software-profile.yaml作为唯一事实源，再进入材料生成。

验证成功的标志有三个：项目被自动扫描、evidence-map.json生成、Agent 用自然语言问现实事实而不是甩表单。三个都出现，说明 Skill 在 TaoToken 通道下正常触发。

5. 本篇常见错排查

配置和调用过程中，最容易踩的坑集中在这几类。

Key 没生效。现象是请求返回 401 或提示未授权。先确认环境变量真的导出了：echo $TAOTOKEN_API_KEY看有没有值。如果是在 IDE 内置终端里跑 Agent，注意 IDE 可能没继承你 shell 的环境变量，需要在 IDE 的启动配置里单独设置，或者把 Key 写进对应工具的配置文件。

base_url 拼错。现象是 404 或连接被拒。TaoToken 的 API 地址是https://taotoken.net/api，不要写成带/v1结尾再让客户端自己拼，也不要带末尾斜杠。不同客户端对路径拼接的处理不一样，统一用不带斜杠的根地址最稳。

Skill 没被识别。现象是 Agent 完全不知道 Copyright Forge 的存在，你让它做软著，它直接开始编文档。检查 skills 路径配置是否指向了软链接所在目录，以及软链接是否有效：ls -l ~/.codex/skills/copyright-forge看箭头指向对不对。软链接断了就重新建。

改了配置没重启会话。Codex、Claude Code、OpenCode 大多在会话启动时读取配置和 Skill 列表。改完配置或装完 Skill，一定要退出当前会话重新开一个，否则改动不生效。

Skill 自更新被跳过。Copyright Forge 每天第一次执行任务前会检查上游版本，如果检测到本地仓库有修改，会停止更新并提示。这是保护机制，不是 bug。想恢复自动更新，把本地改动提交或还原即可。

项目被误改。Copyright Forge 的设计是只读处理原始项目，只对生成的材料副本做安全检查。如果你发现原始项目文件被动了，检查是不是手动执行了仓库里的脚本，正常通过 Agent 触发不会修改源项目。

6. 把通道和 Skill 固定下来

配置这件事，一次做对，后面就省心。我的建议是把 TaoToken 的 Key 统一放在环境变量里，三个 Agent 共用；Skill 用软链接挂载，仓库单独维护，这样 Skill 升级时不用重新配置。验证通过后，你手里就有一套稳定的软著材料工作流：打开项目，说一句“帮我给这个项目做软著”，剩下的交给 Agent。

需要长期跑编码和 Agent 任务的，可以看 Coding Plan，把常用模型额度固定下来：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=coding-plan

想先手动验证模型对话效果的，用模型对话页面：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=model-chat

接入文档和参数细节在这里：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=doc

Key 管理和新建：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=api-keys

Claude Code 相关接入说明：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=claude-code-anthropic

控制台总入口：https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=console

最后留一个实操建议：拿一个你真实写完、但还没申请软著的项目跑一遍完整流程，重点看evidence-map.json里的功能是不是都能对应到真实代码。如果某个功能找不到证据，那就是该删的功能，而不是该补的文案。这一步走通，你对整套工作流的信任就建立起来了。