1. 群聊 Agent 报 401 与重复扣费先把登录 Cookie 和调用 Key 拆开群聊里三个 Bot 同时报401 Invalid API key或者某个 Agent 被踢出群后整条自动化链一起失效这类问题通常不是模型智商不够而是登录态和调用凭证被混在一起。给群聊 Agent 配调用 Key 前先去 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cookie_lead 获取 KeyBase URL 填 https://taotoken.net/api然后把 Cookie 和 Key 分两条线管理Cookie 解决“以谁的身份读群聊”Key 解决“用哪个模型、花谁的 Token”。很多团队一开始图省事把同一个群聊账号的 Cookie 写进系统提示词再把同一个 API Key 塞给所有机器人。结果就是巡检机器人本来只该看任务队列却拿到了管理员登录态值班 Agent 本来只该在被 时回消息却因为轮询把整个群的历史消息都塞进上下文草稿 Agent 只做差分却和聊天 Agent 共用一个 Key最后看用量时根本不知道谁在烧 Token。这场 Grok Bot 创始人会议里被反复提到的一个判断很值得抄进制度让自动化系统崩塌的往往不是模型不够聪明而是缺少成本审计和权限隔离。本文不复述会议观点直接给一套可跟做的配置路径先把 Cookie 按最小权限下发表拆开再把 API 调用、巡检机器人、草稿差分、群聊静默策略分别落到配置里。最后你会得到一张能贴进团队文档的权限表以及一套能立刻跑起来的 Key 与 Base URL 配置。2. 群聊 Cookie 最小权限下发表每个 Agent 只拿它必须的登录态群聊 Agent 最危险的地方不是“它会说话”而是“它带着登录态说话”。一个 Cookie 如果既能读所有群、又能发消息、还能改群设置那它就不该出现在任何自动化流程里。最小权限下发的原则是能不给 Cookie 就不给必须给就只给只读、限群、限时、限操作的 Cookie并且 Cookie 不写进提示词不提交到仓库不通过群聊消息传递。下面这张表可以直接作为团队模板。你可以把它复制到文档里按实际 Agent 名称替换。重点看最后一列每个 Agent 必须绑定独立调用 Key这样才能在 TaoToken 控制台或 API Keys 页面标注“哪个 Agent 消耗 Token”。Agent 名称登录 Cookie 权限群聊可见范围发言策略独立调用 Key 标识日 Token 预算Token 消耗标注巡检机器人不发放 Cookie不读群聊不发言key-patrol-bot200k仅巡检任务队列调用草稿差分 Agent不发放 Cookie不读群聊不发言key-diff-agent500k每次终稿/草稿差分群聊值班 Agent只读 Cookie限 1 个群仅被授权群仅 点名时回复key-chat-duty800k回复、检索、总结管理员助手不发放 Cookie不读群聊仅私聊key-admin-helper100k管理命令与审批工单同步 Agent不发放 Cookie不读群聊不发言key-ticket-sync300k工单状态同步这张表的关键不是列得好看而是执行三件事第一Cookie 与 Key 分离。Cookie 放在专门的密钥管理服务里按 Agent 单独发放。群聊值班 Agent 只用只读 Cookie不允许发消息以外的任何写操作。发消息权限可以通过群聊平台的机器人身份实现而不是把真人账号的完整 Cookie 交出去。第二每个 Agent 一个 Key。不要用“团队公共 Key”。公共 Key 的后果是某个 Agent 出现死循环你只能看到总用量暴涨却不知道是谁。独立 Key 的命名建议带上环境、角色、负责人例如prod-chat-duty-a1、test-diff-agent。TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_perm_table 可以进入控制台创建和管理这些 KeyBase URL 仍然是 https://taotoken.net/api。第三巡检机器人不拿 Cookie。它的职责是清理空转任务不是读群聊。它只需要调用任务队列的本地 API发现超过阈值未更新的任务就标记为 stale然后通知负责人。把巡检机器人放进群聊并给它 Cookie等于让一个只该看任务状态的进程拥有读群消息的能力这是权限溢出。Cookie 最小权限还可以加两个限制限时与限 IP。限时是指 Cookie 只在值班时间段内有效下班后自动失效限 IP 是指只允许部署 Agent 的那台机器或那个出口访问。群聊平台如果不支持细粒度 Cookie至少要做到“只读、限群、不落盘明文”。任何把 Cookie 粘贴到系统提示词、README、群公告里的做法都应该在代码评审阶段直接打回。3. 能用 API 就不让 Agent 模拟点击TaoToken 调用链与空转巡检机器人模拟点击屏幕看起来很快打开网页、找到按钮、点一下、截图确认。但放到群聊 Agent 里它会带来三个长期成本。第一不稳定。页面改版、弹窗、加载慢都会让点击链断掉。第二权限过大。为了点击Agent 往往需要登录态、浏览器控制权、甚至桌面控制权。第三Token 消耗不可审计。视觉模型每看一次截图都在烧 Token而你很难判断这次点击到底值不值。能用 API 就用 API。群聊 Agent 需要模型能力时统一走 TaoToken 的 Base URLhttps://taotoken.net/apiKey 使用YOUR_API_KEY占位实际值放在环境变量或密钥管理服务里。这样调用链是清晰的Agent 进程 → TaoToken API → 模型返回 → Agent 按策略发言或执行本地命令。不要让 Agent 去点屏幕完成“查任务状态”这种事任务状态应该由本地巡检机器人通过 HTTP API 读取。下面是一个本地巡检机器人的最小示例。命令由你在自己机器上执行不要把它接到生产库也不要让 Agent 直接执行数据库命令。这里假设任务队列有一个只读接口返回 JSON 数组#!/usr/bin/env bash # 本地执行每小时检查一次空转任务 set -euo pipefail TASK_APIhttps://your-task-queue.local/api/tasks?statusrunning TASK_TOKENYOUR_TASK_QUEUE_TOKEN STALE_SECONDS600 curl -s $TASK_API \ -H Authorization: Bearer $TASK_TOKEN \ | jq --argjson stale $STALE_SECONDS .[] | select((.updated_at | fromdateiso8601) (now - $stale)) | {id, owner, updated_at, status} 如果输出不为空说明有任务超过 10 分钟没有更新。巡检机器人可以做的动作是把任务 ID、负责人、最后更新时间推送到管理员频道或者调用本地工单系统标记“待确认”。注意它不需要登录群聊也不需要模拟点击。它只做一件事清理空转。清理空转还有一层成本意义。群聊 Agent 如果一直轮询、一直总结、一直互相回复Token 消耗会像漏水一样慢慢涨。巡检机器人应该同时检查两类信号任务队列里的 stale 任务以及 Agent 调用日志里的异常频率。比如同一个 Key 在 10 分钟内请求超过 100 次就应该触发告警。独立 Key 在这里非常关键没有独立 Key你只能看到总账单有了独立 Key你能直接定位到key-chat-duty还是key-diff-agent在空转。如果你还没有创建这些 Key可以在 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_inspect 进入控制台按 Agent 角色分别创建。创建后先写进本地.env不要写进代码仓库# 本地 .env 示例不要提交到 git TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api4. 终稿与草稿差分对比把群聊里的纠正固化成长期技能群聊里最常见的浪费是“重复教”。今天有人纠正 Agent不要把草稿里的推测写成事实。明天换了个人又纠正一遍。后天 Agent 继续犯。问题不在于模型没有记住而在于纠正逻辑没有变成可检索、可复用的长期技能。更有效的做法是每次群聊值班 Agent 产出草稿后由人工改出终稿再把草稿与终稿做差分把差分里的纠正规则抽出来写入技能库。差分不是让你把整段对话塞回上下文。上下文越长成本越高噪声越大。你要保存的是“从草稿到终稿发生了什么变化”。下面是一个本地脚本示例把草稿和终稿的 unified diff 写入 JSONL 文件。命令由你本地执行文件路径按实际情况替换# 本地执行把草稿与终稿的差分写入技能库 import difflib import json from pathlib import Path draft_path Path(draft.md) final_path Path(final.md) skill_path Path(skills.jsonl) draft_lines draft_path.read_text(encodingutf-8).splitlines() final_lines final_path.read_text(encodingutf-8).splitlines() diff_lines list( difflib.unified_diff( draft_lines, final_lines, fromfiledraft, tofilefinal, lineterm, ) ) record { source: group_chat_duty, agent_key: key-chat-duty, draft_hash: hash(\n.join(draft_lines)), final_hash: hash(\n.join(final_lines)), diff: diff_lines, } with skill_path.open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)运行后skills.jsonl会积累一条条“纠正记录”。接下来要做的是定期把这些记录归类例如事实性错误草稿写了没有来源的结论终稿删除了。格式错误草稿用了口语终稿改成结构化列表。权限错误草稿试图读取未授权群终稿改为只读授权群。成本错误草稿让 Agent 轮询全部历史消息终稿改为只读最近 N 条。归类后把高频规则写成 Agent 的检索前置条件。比如值班 Agent 在回复前先查技能库如果本次任务命中“事实性错误”规则就先要求给出处没有出处就不发。这个过程不需要让 Agent 直接连数据库也不需要让 Agent 模拟点击。它只需要通过 TaoToken API 做模型判断然后把结果写回本地技能库。差分对比的价值在于它把群聊里的人工纠正变成了可复用的制度而不是每次重新教一遍。5. Claude Code / Codex / CC Switch 三件套配置分开写别混用群聊 Agent 的调用 Key 和 Base URL 配置和本地开发工具是同一套底层凭证但配置文件要分开。尤其是 Claude Code 和 Codex环境变量名完全不同。把ANTHROPIC_*套到 Codex 上最常见的结果是工具读不到 Key报 401 或直接走默认地址。下面给两组可复制配置。Claude Code 使用settings.json核心是ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN和模型 ID。Base URL 填https://taotoken.net/apiKey 先用YOUR_API_KEY占位{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }Codex 使用config.toml不要写ANTHROPIC_*。它的供应商配置里写base_url和env_key实际 Key 放在环境变量里model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses对应的环境变量在本地 shell 里设置不要提交到仓库export TAOTOKEN_API_KEYYOUR_API_KEY如果你使用 CC Switch 管理多个供应商建议把它当成“三件套”来维护供应商地址、密钥、模型。每个 profile 只改这三项不要在不同工具之间复制环境变量名。Claude Code profile 里出现ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN是正常的Codex profile 里应该出现base_url、env_key而不是ANTHROPIC_*。群聊 Agent 也可以复用这套思路每个 Agent 一个 profileprofile 名称与 Key 名称一致例如chat-duty、diff-agent、patrol-bot。如果你还没有拿到 Key可以在 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cc_switch 进入控制台创建。创建后先做一次最小连通性测试用 Claude Code 发一条只读请求再用 Codex 发一条只读请求确认两边都不报 401。测试通过后再把 Key 分发给群聊 Agent。6. 成本审计与权限隔离制度谁消耗 Token谁被点名群聊 Agent 默认静默、仅在点名时发言这不是为了“显得礼貌”而是为了控制成本和权限边界。一个 Agent 如果在群里持续监听、持续总结、持续插话它就会持续消耗 Token并且持续读取不该读的消息。正确的默认策略是监听但沉默只有被 或命中明确关键词时才进入回复流程。下面是一段可参考的群聊策略配置实际字段按你的机器人框架替换group_agents: default_mode: silent triggers: - type: mention value: 值班Bot - type: keyword value: 需要人工确认 reply_policy: only_on_trigger: true max_replies_per_hour: 6 context_window: max_messages: 30 exclude_channels: - #财务 - #人事 cookie_policy: enabled: true scope: read_only allowed_groups: - group_ops_room ttl_minutes: 120这段配置做了四件事默认静默只在点名或关键词时回复限制每小时回复次数Cookie 只读、限群、限时。再加上独立 Key就能做成本审计。建议每天检查一次下面这张审计表审计项数据来源异常阈值处理动作单 Key 日 Token 消耗TaoToken 控制台 / API Keys超过日预算 80%通知负责人暂停非关键任务群聊值班 Agent 回复次数本地日志每小时超过 6 次检查是否误触发关键词巡检机器人空转清理数任务队列日志连续 3 小时为 0检查队列接口是否正常草稿差分写入量skills.jsonl一天超过 200 条检查是否重复纠正同一问题Cookie 使用范围密钥管理服务出现未授权群立即吊销并重新下发这张表的核心是“谁消耗 Token谁被点名”。不要等月底看总账单。群聊 Agent 的成本是实时发生的权限也是实时暴露的。把独立 Key、Cookie 最小权限、默认静默、巡检机器人四件事做完你才有一个可审计的系统。缺了成本审计模型再聪明也会被空转拖垮缺了权限隔离任何一个 Agent 出错都可能影响整个群聊。7. 上线检查清单与 CTA模型对话、Coding Plan、创建 Key、Claude Code 文档把上面的内容压缩成上线前检查清单逐项确认每个群聊 Agent 是否有独立 Key并且 Key 名称能对应到 Agent 角色。Cookie 是否做到只读、限群、限时、不落盘明文是否与 Key 分离。Base URL 是否统一填写https://taotoken.net/api没有混用其他地址。Claude Code 是否使用settings.json与ANTHROPIC_*Codex 是否使用config.toml且没有把ANTHROPIC_*写进 Codex。巡检机器人是否在不读取群聊 Cookie 的前提下清理空转任务。草稿与终稿差分是否写入技能库并定期归类为可复用规则。群聊默认静默、点名才发言是否配置了每小时回复上限。是否每天检查一次单 Key Token 消耗、回复次数、Cookie 使用范围。是否为每个 Agent 设置了日 Token 预算和异常告警。是否把 Key 和 Cookie 放在密钥管理服务而不是代码仓库或群公告。完成检查后推荐按下面路径继续配置先在模型对话里验证模型连通性与返回格式https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_chat如果群聊 Agent 需要长期跑编码、总结、巡检任务可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_plan为每个 Agent 创建独立 Key并按角色命名https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_keysClaude Code 的完整配置说明在文档里https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cc_doc最后再强调一次群聊 Agent 的权限隔离不是“上线后再补”的安全项而是第一行配置就要写对的基础设施。Cookie 按最小权限下发Key 按 Agent 独立创建Base URL 统一填https://taotoken.net/api巡检机器人清理空转差分对比固化纠正逻辑群聊默认静默、点名才发言。把这些动作做完你看到的就不再是一团共用凭证的机器人而是一套能审计、能限权、能控制成本的群聊 Agent 系统。TaoToken 官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_final 管住群聊 Agent 的 Cookie，TaoToken 按最小权限下发
1. 群聊 Agent 报 401 与重复扣费先把登录 Cookie 和调用 Key 拆开群聊里三个 Bot 同时报401 Invalid API key或者某个 Agent 被踢出群后整条自动化链一起失效这类问题通常不是模型智商不够而是登录态和调用凭证被混在一起。给群聊 Agent 配调用 Key 前先去 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cookie_lead 获取 KeyBase URL 填 https://taotoken.net/api然后把 Cookie 和 Key 分两条线管理Cookie 解决“以谁的身份读群聊”Key 解决“用哪个模型、花谁的 Token”。很多团队一开始图省事把同一个群聊账号的 Cookie 写进系统提示词再把同一个 API Key 塞给所有机器人。结果就是巡检机器人本来只该看任务队列却拿到了管理员登录态值班 Agent 本来只该在被 时回消息却因为轮询把整个群的历史消息都塞进上下文草稿 Agent 只做差分却和聊天 Agent 共用一个 Key最后看用量时根本不知道谁在烧 Token。这场 Grok Bot 创始人会议里被反复提到的一个判断很值得抄进制度让自动化系统崩塌的往往不是模型不够聪明而是缺少成本审计和权限隔离。本文不复述会议观点直接给一套可跟做的配置路径先把 Cookie 按最小权限下发表拆开再把 API 调用、巡检机器人、草稿差分、群聊静默策略分别落到配置里。最后你会得到一张能贴进团队文档的权限表以及一套能立刻跑起来的 Key 与 Base URL 配置。2. 群聊 Cookie 最小权限下发表每个 Agent 只拿它必须的登录态群聊 Agent 最危险的地方不是“它会说话”而是“它带着登录态说话”。一个 Cookie 如果既能读所有群、又能发消息、还能改群设置那它就不该出现在任何自动化流程里。最小权限下发的原则是能不给 Cookie 就不给必须给就只给只读、限群、限时、限操作的 Cookie并且 Cookie 不写进提示词不提交到仓库不通过群聊消息传递。下面这张表可以直接作为团队模板。你可以把它复制到文档里按实际 Agent 名称替换。重点看最后一列每个 Agent 必须绑定独立调用 Key这样才能在 TaoToken 控制台或 API Keys 页面标注“哪个 Agent 消耗 Token”。Agent 名称登录 Cookie 权限群聊可见范围发言策略独立调用 Key 标识日 Token 预算Token 消耗标注巡检机器人不发放 Cookie不读群聊不发言key-patrol-bot200k仅巡检任务队列调用草稿差分 Agent不发放 Cookie不读群聊不发言key-diff-agent500k每次终稿/草稿差分群聊值班 Agent只读 Cookie限 1 个群仅被授权群仅 点名时回复key-chat-duty800k回复、检索、总结管理员助手不发放 Cookie不读群聊仅私聊key-admin-helper100k管理命令与审批工单同步 Agent不发放 Cookie不读群聊不发言key-ticket-sync300k工单状态同步这张表的关键不是列得好看而是执行三件事第一Cookie 与 Key 分离。Cookie 放在专门的密钥管理服务里按 Agent 单独发放。群聊值班 Agent 只用只读 Cookie不允许发消息以外的任何写操作。发消息权限可以通过群聊平台的机器人身份实现而不是把真人账号的完整 Cookie 交出去。第二每个 Agent 一个 Key。不要用“团队公共 Key”。公共 Key 的后果是某个 Agent 出现死循环你只能看到总用量暴涨却不知道是谁。独立 Key 的命名建议带上环境、角色、负责人例如prod-chat-duty-a1、test-diff-agent。TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_perm_table 可以进入控制台创建和管理这些 KeyBase URL 仍然是 https://taotoken.net/api。第三巡检机器人不拿 Cookie。它的职责是清理空转任务不是读群聊。它只需要调用任务队列的本地 API发现超过阈值未更新的任务就标记为 stale然后通知负责人。把巡检机器人放进群聊并给它 Cookie等于让一个只该看任务状态的进程拥有读群消息的能力这是权限溢出。Cookie 最小权限还可以加两个限制限时与限 IP。限时是指 Cookie 只在值班时间段内有效下班后自动失效限 IP 是指只允许部署 Agent 的那台机器或那个出口访问。群聊平台如果不支持细粒度 Cookie至少要做到“只读、限群、不落盘明文”。任何把 Cookie 粘贴到系统提示词、README、群公告里的做法都应该在代码评审阶段直接打回。3. 能用 API 就不让 Agent 模拟点击TaoToken 调用链与空转巡检机器人模拟点击屏幕看起来很快打开网页、找到按钮、点一下、截图确认。但放到群聊 Agent 里它会带来三个长期成本。第一不稳定。页面改版、弹窗、加载慢都会让点击链断掉。第二权限过大。为了点击Agent 往往需要登录态、浏览器控制权、甚至桌面控制权。第三Token 消耗不可审计。视觉模型每看一次截图都在烧 Token而你很难判断这次点击到底值不值。能用 API 就用 API。群聊 Agent 需要模型能力时统一走 TaoToken 的 Base URLhttps://taotoken.net/apiKey 使用YOUR_API_KEY占位实际值放在环境变量或密钥管理服务里。这样调用链是清晰的Agent 进程 → TaoToken API → 模型返回 → Agent 按策略发言或执行本地命令。不要让 Agent 去点屏幕完成“查任务状态”这种事任务状态应该由本地巡检机器人通过 HTTP API 读取。下面是一个本地巡检机器人的最小示例。命令由你在自己机器上执行不要把它接到生产库也不要让 Agent 直接执行数据库命令。这里假设任务队列有一个只读接口返回 JSON 数组#!/usr/bin/env bash # 本地执行每小时检查一次空转任务 set -euo pipefail TASK_APIhttps://your-task-queue.local/api/tasks?statusrunning TASK_TOKENYOUR_TASK_QUEUE_TOKEN STALE_SECONDS600 curl -s $TASK_API \ -H Authorization: Bearer $TASK_TOKEN \ | jq --argjson stale $STALE_SECONDS .[] | select((.updated_at | fromdateiso8601) (now - $stale)) | {id, owner, updated_at, status} 如果输出不为空说明有任务超过 10 分钟没有更新。巡检机器人可以做的动作是把任务 ID、负责人、最后更新时间推送到管理员频道或者调用本地工单系统标记“待确认”。注意它不需要登录群聊也不需要模拟点击。它只做一件事清理空转。清理空转还有一层成本意义。群聊 Agent 如果一直轮询、一直总结、一直互相回复Token 消耗会像漏水一样慢慢涨。巡检机器人应该同时检查两类信号任务队列里的 stale 任务以及 Agent 调用日志里的异常频率。比如同一个 Key 在 10 分钟内请求超过 100 次就应该触发告警。独立 Key 在这里非常关键没有独立 Key你只能看到总账单有了独立 Key你能直接定位到key-chat-duty还是key-diff-agent在空转。如果你还没有创建这些 Key可以在 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_inspect 进入控制台按 Agent 角色分别创建。创建后先写进本地.env不要写进代码仓库# 本地 .env 示例不要提交到 git TAOTOKEN_API_KEYYOUR_API_KEY TAOTOKEN_BASE_URLhttps://taotoken.net/api4. 终稿与草稿差分对比把群聊里的纠正固化成长期技能群聊里最常见的浪费是“重复教”。今天有人纠正 Agent不要把草稿里的推测写成事实。明天换了个人又纠正一遍。后天 Agent 继续犯。问题不在于模型没有记住而在于纠正逻辑没有变成可检索、可复用的长期技能。更有效的做法是每次群聊值班 Agent 产出草稿后由人工改出终稿再把草稿与终稿做差分把差分里的纠正规则抽出来写入技能库。差分不是让你把整段对话塞回上下文。上下文越长成本越高噪声越大。你要保存的是“从草稿到终稿发生了什么变化”。下面是一个本地脚本示例把草稿和终稿的 unified diff 写入 JSONL 文件。命令由你本地执行文件路径按实际情况替换# 本地执行把草稿与终稿的差分写入技能库 import difflib import json from pathlib import Path draft_path Path(draft.md) final_path Path(final.md) skill_path Path(skills.jsonl) draft_lines draft_path.read_text(encodingutf-8).splitlines() final_lines final_path.read_text(encodingutf-8).splitlines() diff_lines list( difflib.unified_diff( draft_lines, final_lines, fromfiledraft, tofilefinal, lineterm, ) ) record { source: group_chat_duty, agent_key: key-chat-duty, draft_hash: hash(\n.join(draft_lines)), final_hash: hash(\n.join(final_lines)), diff: diff_lines, } with skill_path.open(a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)运行后skills.jsonl会积累一条条“纠正记录”。接下来要做的是定期把这些记录归类例如事实性错误草稿写了没有来源的结论终稿删除了。格式错误草稿用了口语终稿改成结构化列表。权限错误草稿试图读取未授权群终稿改为只读授权群。成本错误草稿让 Agent 轮询全部历史消息终稿改为只读最近 N 条。归类后把高频规则写成 Agent 的检索前置条件。比如值班 Agent 在回复前先查技能库如果本次任务命中“事实性错误”规则就先要求给出处没有出处就不发。这个过程不需要让 Agent 直接连数据库也不需要让 Agent 模拟点击。它只需要通过 TaoToken API 做模型判断然后把结果写回本地技能库。差分对比的价值在于它把群聊里的人工纠正变成了可复用的制度而不是每次重新教一遍。5. Claude Code / Codex / CC Switch 三件套配置分开写别混用群聊 Agent 的调用 Key 和 Base URL 配置和本地开发工具是同一套底层凭证但配置文件要分开。尤其是 Claude Code 和 Codex环境变量名完全不同。把ANTHROPIC_*套到 Codex 上最常见的结果是工具读不到 Key报 401 或直接走默认地址。下面给两组可复制配置。Claude Code 使用settings.json核心是ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN和模型 ID。Base URL 填https://taotoken.net/apiKey 先用YOUR_API_KEY占位{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }Codex 使用config.toml不要写ANTHROPIC_*。它的供应商配置里写base_url和env_key实际 Key 放在环境变量里model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses对应的环境变量在本地 shell 里设置不要提交到仓库export TAOTOKEN_API_KEYYOUR_API_KEY如果你使用 CC Switch 管理多个供应商建议把它当成“三件套”来维护供应商地址、密钥、模型。每个 profile 只改这三项不要在不同工具之间复制环境变量名。Claude Code profile 里出现ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN是正常的Codex profile 里应该出现base_url、env_key而不是ANTHROPIC_*。群聊 Agent 也可以复用这套思路每个 Agent 一个 profileprofile 名称与 Key 名称一致例如chat-duty、diff-agent、patrol-bot。如果你还没有拿到 Key可以在 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cc_switch 进入控制台创建。创建后先做一次最小连通性测试用 Claude Code 发一条只读请求再用 Codex 发一条只读请求确认两边都不报 401。测试通过后再把 Key 分发给群聊 Agent。6. 成本审计与权限隔离制度谁消耗 Token谁被点名群聊 Agent 默认静默、仅在点名时发言这不是为了“显得礼貌”而是为了控制成本和权限边界。一个 Agent 如果在群里持续监听、持续总结、持续插话它就会持续消耗 Token并且持续读取不该读的消息。正确的默认策略是监听但沉默只有被 或命中明确关键词时才进入回复流程。下面是一段可参考的群聊策略配置实际字段按你的机器人框架替换group_agents: default_mode: silent triggers: - type: mention value: 值班Bot - type: keyword value: 需要人工确认 reply_policy: only_on_trigger: true max_replies_per_hour: 6 context_window: max_messages: 30 exclude_channels: - #财务 - #人事 cookie_policy: enabled: true scope: read_only allowed_groups: - group_ops_room ttl_minutes: 120这段配置做了四件事默认静默只在点名或关键词时回复限制每小时回复次数Cookie 只读、限群、限时。再加上独立 Key就能做成本审计。建议每天检查一次下面这张审计表审计项数据来源异常阈值处理动作单 Key 日 Token 消耗TaoToken 控制台 / API Keys超过日预算 80%通知负责人暂停非关键任务群聊值班 Agent 回复次数本地日志每小时超过 6 次检查是否误触发关键词巡检机器人空转清理数任务队列日志连续 3 小时为 0检查队列接口是否正常草稿差分写入量skills.jsonl一天超过 200 条检查是否重复纠正同一问题Cookie 使用范围密钥管理服务出现未授权群立即吊销并重新下发这张表的核心是“谁消耗 Token谁被点名”。不要等月底看总账单。群聊 Agent 的成本是实时发生的权限也是实时暴露的。把独立 Key、Cookie 最小权限、默认静默、巡检机器人四件事做完你才有一个可审计的系统。缺了成本审计模型再聪明也会被空转拖垮缺了权限隔离任何一个 Agent 出错都可能影响整个群聊。7. 上线检查清单与 CTA模型对话、Coding Plan、创建 Key、Claude Code 文档把上面的内容压缩成上线前检查清单逐项确认每个群聊 Agent 是否有独立 Key并且 Key 名称能对应到 Agent 角色。Cookie 是否做到只读、限群、限时、不落盘明文是否与 Key 分离。Base URL 是否统一填写https://taotoken.net/api没有混用其他地址。Claude Code 是否使用settings.json与ANTHROPIC_*Codex 是否使用config.toml且没有把ANTHROPIC_*写进 Codex。巡检机器人是否在不读取群聊 Cookie 的前提下清理空转任务。草稿与终稿差分是否写入技能库并定期归类为可复用规则。群聊默认静默、点名才发言是否配置了每小时回复上限。是否每天检查一次单 Key Token 消耗、回复次数、Cookie 使用范围。是否为每个 Agent 设置了日 Token 预算和异常告警。是否把 Key 和 Cookie 放在密钥管理服务而不是代码仓库或群公告。完成检查后推荐按下面路径继续配置先在模型对话里验证模型连通性与返回格式https://taotoken.net/models/detail/chat?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_chat如果群聊 Agent 需要长期跑编码、总结、巡检任务可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_plan为每个 Agent 创建独立 Key并按角色命名https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_keysClaude Code 的完整配置说明在文档里https://taotoken.net/doc/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_cc_doc最后再强调一次群聊 Agent 的权限隔离不是“上线后再补”的安全项而是第一行配置就要写对的基础设施。Cookie 按最小权限下发Key 按 Agent 独立创建Base URL 统一填https://taotoken.net/api巡检机器人清理空转差分对比固化纠正逻辑群聊默认静默、点名才发言。把这些动作做完你看到的就不再是一团共用凭证的机器人而是一套能审计、能限权、能控制成本的群聊 Agent 系统。TaoToken 官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentgroup_agent_final