1. 先拿 KeyLinux 下把 HanaAgent 的 Base URL 切到 TaoTokenLinux 上用 Bubblewrap 跑 HanaAgent 定时任务最常见的两个报错是bwrap: Cant bind /etc/resolv.conf和 Cron 里模型请求 401。先到 TaoToken 官网 拿 KeyBase URL 填https://taotoken.net/api再谈沙盒和 Token 记录。这一步不做后面所有 Cron 任务都会在沙盒里静默失败日志里只有一行unauthorized找半天以为是 Bubblewrap 把网络掐了。HanaAgent 在 Linux 桌面端把操作系统级沙盒交给 Bubblewrap好处是 AI 能碰的路径被硬锁在指定目录坏处是很多“看起来能跑”的脚本一进bwrap就换了一个极简环境PATH变短、HOME变临时目录、/etc/resolv.conf可能不存在。如果你再用 Cron 跑定时任务环境变量比交互式 shell 更少TAOTOKEN_API_KEY没被带进去任务就会以 401 结束。所以本文按“先接 Key、再配沙盒、最后记 Token”的顺序写每一步都给出可复制的配置。先明确三个值供应商 Base URLhttps://taotoken.net/apiAPI Key 占位符YOUR_API_KEYHanaAgent 侧建议写入环境变量TAOTOKEN_BASE_URL、TAOTOKEN_API_KEY如果你还没有 Key从 TaoToken 官网 进入控制台创建后面文末会给完整 CTA 路径。注意HanaAgent 支持 OpenAI 兼容接口和 Anthropic 风格接口但不要把 Anthropic 的变量名塞给 Codex也不要把 Codex 的config.toml直接改名给 Claude Code工具之间只共享 Key 和 Base URL不共享配置格式。Linux 办公自动化场景下我建议把 HanaAgent 的定时任务拆成两层外层是系统计划任务只负责“什么时候启动脚本”内层是 Bubblewrap 沙盒只负责“启动后能看哪些文件、能走哪个网络出口”。这样 Token 日志和沙盒日志可以分开落盘出问题时先看 Cron 日志再看bwrap日志最后看 HanaAgent 自己的任务日志排障路径清晰。2. Bubblewrap 沙盒配置给 HanaAgent 只读系统、可写工作区HanaAgent 在 Linux 上用 Bubblewrap 做 OS 级沙盒核心原则是系统目录只读工作目录可写网络单独放行HOME指向工作目录而不是真实家目录。下面这个bwrap-hanako.sh可以直接放在~/bin/下作为 HanaAgent 定时任务的入口。#!/usr/bin/env bash set -euo pipefail WORKDIR${HANA_WORKDIR:-$HOME/hanako-work} TASK${1:?usage: bwrap-hanako.sh task-name} APP_BIN${HANA_BIN:-/opt/hanaagent/hanaagent} mkdir -p $WORKDIR/{inbox,outbox,logs,state} exec bwrap \ --die-with-parent \ --new-session \ --unshare-pid \ --unshare-ipc \ --unshare-uts \ --unshare-cgroup \ --share-net \ --proc /proc \ --dev /dev \ --tmpfs /tmp \ --ro-bind /usr /usr \ --ro-bind /bin /bin \ --ro-bind /sbin /sbin \ --ro-bind /lib /lib \ --ro-bind /lib64 /lib64 \ --ro-bind /etc/ssl /etc/ssl \ --ro-bind-try /etc/resolv.conf /etc/resolv.conf \ --ro-bind-try /etc/hosts /etc/hosts \ --ro-bind-try /etc/nsswitch.conf /etc/nsswitch.conf \ --ro-bind-try /etc/passwd /etc/passwd \ --ro-bind-try /etc/group /etc/group \ --bind $WORKDIR $WORKDIR \ --chdir $WORKDIR \ --setenv HOME $WORKDIR \ --setenv PATH /usr/local/bin:/usr/bin:/bin \ --setenv HANA_WORKDIR $WORKDIR \ --setenv TAOTOKEN_BASE_URL https://taotoken.net/api \ --setenv TAOTOKEN_API_KEY YOUR_API_KEY \ --setenv OPENAI_BASE_URL https://taotoken.net/api \ --setenv OPENAI_API_KEY YOUR_API_KEY \ --setenv ANTHROPIC_BASE_URL https://taotoken.net/api \ --setenv ANTHROPIC_API_KEY YOUR_API_KEY \ --cap-drop ALL \ $APP_BIN --headless --task $TASK几个容易踩坑的点第一--ro-bind-try比--ro-bind更适合/etc/resolv.conf、/etc/hosts这类文件。不同发行版里它们可能是符号链接直接--ro-bind会在某些机器上报No such file or directory。加-try后文件不存在也不会把整个沙盒启动搞崩。第二--share-net是必须的。HanaAgent 要调https://taotoken.net/api如果完全隔离网络模型请求会直接超时。这里没有做“只允许某个域名”的精细网络策略因为 Bubblewrap 本身不是防火墙如果你需要更细的网络控制可以在宿主机上用nftables或cgroup限制但别把生产库地址暴露给 Agent。第三HOME被设成$WORKDIR所以 HanaAgent 写入的缓存、状态文件都会落在~/hanako-work里不会污染真实家目录。你可以在state/下放角色卡、技能包、任务模板在inbox/下放待处理文件在outbox/下接结果文件。第四应用目录/opt/hanaagent没有被绑定。如果 HanaAgent 是 AppImage 或解压目录需要把它的运行目录也加进去--ro-bind /opt/hanaagent /opt/hanaagent \如果还依赖 Electron 的共享库通常/usr、/lib、/lib64已经覆盖。缺哪个库bwrap会在启动时报error while loading shared libraries按报错补只读绑定即可。第五不要给 Agent 绑定$HOME/.ssh、$HOME/.config、/var/run/docker.sock。这些路径一旦进入沙盒PathGuard 的白名单意义就被削弱了。HanaAgent 的双层沙盒里PathGuard 负责路径白名单Bubblewrap 负责系统级隔离两者叠加才有效。3. Cron 包装脚本让定时任务在沙盒里准点跑有了 Bubblewrap 入口下一步是让 Cron 调用它。不要直接在crontab里写一长串bwrap参数Cron 环境太干净排障也难看。用一个包装脚本hanako-cron.sh统一处理日志、退出码和 Token 记录#!/usr/bin/env bash set -euo pipefail set -o pipefail TASK${1:?task required} WORKDIR${HANA_WORKDIR:-$HOME/hanako-work} LOG_DIR$WORKDIR/logs mkdir -p $LOG_DIR STAMP$(date %Y%m%dT%H%M%S) RAW_LOG$LOG_DIR/${TASK}-${STAMP}.jsonl $HOME/bin/bwrap-hanako.sh $TASK | tee $RAW_LOG $HOME/bin/token-ledger.sh $RAW_LOG $TASK对应的crontab -e可以这样写# 每天 09:10 巡检 inbox生成待归档清单 10 9 * * * /home/you/bin/hanako-cron.sh daily-inbox /home/you/hanako-work/logs/cron.log 21 # 每周五 16:30 汇总本周文档生成周报草稿 30 16 * * 5 /home/you/bin/hanako-cron.sh weekly-report /home/you/hanako-work/logs/cron.log 21 # 每天 18:00 检查 outbox把结果文件按日期归档 0 18 * * * /home/you/bin/hanako-cron.sh archive-outbox /home/you/hanako-work/logs/cron.log 21如果你的发行版默认没有 Cron 服务用 systemd user timer 也可以。创建~/.config/systemd/user/hanako-daily.service[Unit] DescriptionHanaAgent daily inbox task in Bubblewrap Afternetwork-online.target [Service] Typeoneshot WorkingDirectory%h/hanako-work ExecStart%h/bin/hanako-cron.sh daily-inbox EnvironmentHANA_WORKDIR%h/hanako-work再创建~/.config/systemd/user/hanako-daily.timer[Unit] DescriptionRun HanaAgent daily inbox task [Timer] OnCalendar*-*-* 09:10:00 Persistenttrue [Install] WantedBytimers.target启用systemctl --user daemon-reload systemctl --user enable --now hanako-daily.timer systemctl --user list-timers | grep hanakosystemd user timer 的好处是日志可以直接进 journaljournalctl --user -u hanako-daily.service -n 100 --no-pagerCron 和 systemd timer 二选一即可不要同时启用否则同一个任务会跑两次Token 消耗也翻倍。4. Token 记录每次 Cron 任务写一行 JSONL 账单省 Token 的前提是知道 Token 花在哪。HanaAgent 的定时任务如果开启详细日志模型响应里通常会带usage字段。我们写一个token-ledger.sh从原始日志里抽取用量追加到token-ledger.jsonl。这样每周用jq汇总一次就能看到哪个任务最费 Token。#!/usr/bin/env bash set -euo pipefail RAW_LOG${1:?raw log required} TASK${2:?task required} WORKDIR${HANA_WORKDIR:-$HOME/hanako-work} LEDGER$WORKDIR/logs/token-ledger.jsonl mkdir -p $(dirname $LEDGER) jq -c --arg task $TASK --arg ts $(date -Iseconds) select(.usage ! null) | { ts: $ts, task: $task, model: (.model // unknown), input_tokens: (.usage.prompt_tokens // .usage.input_tokens // 0), output_tokens: (.usage.completion_tokens // .usage.output_tokens // 0), total_tokens: ( (.usage.prompt_tokens // .usage.input_tokens // 0) (.usage.completion_tokens // .usage.output_tokens // 0) ) } $RAW_LOG $LEDGER 2/dev/null || true如果 HanaAgent 的日志不是严格 JSON而是这种文本格式[2026-08-29 09:10:12] taskdaily-inbox modelcheap-chat prompt_tokens1832 completion_tokens240可以用awk兜底awk match($0, /task([^ ])/, t) match($0, /model([^ ])/, m) match($0, /prompt_tokens([0-9])/, p) match($0, /completion_tokens([0-9])/, c) { printf {\ts\:\%s\,\task\:\%s\,\model\:\%s\,\input_tokens\:%d,\output_tokens\:%d,\total_tokens\:%d}\n, strftime(%Y-%m-%dT%H:%M:%S), t[1], m[1], p[1], c[1], p[1]c[1] } $RAW_LOG $LEDGER每周汇总jq -s group_by(.task) | map({ task: .[0].task, runs: length, input: (map(.input_tokens) | add), output: (map(.output_tokens) | add), total: (map(.total_tokens) | add) }) | sort_by(.total) | reverse $HOME/hanako-work/logs/token-ledger.jsonl只想看当天TODAY$(date %F) jq -s --arg today $TODAY map(select(.ts | startswith($today))) | group_by(.task) | map({task: .[0].task, total: (map(.total_tokens) | add)}) $HOME/hanako-work/logs/token-ledger.jsonl如果你在 TaoToken 控制台里也看用量可以把两边对一下控制台看总消耗本地token-ledger.jsonl看任务级分布。控制台入口在 TaoToken 官网登录后进 API Keys 或用量页面即可。注意别把 Key 写进日志token-ledger.sh只记录 token 数字和模型名不记录请求头。5. 省 Token 的实操模型分级、心跳降频、上下文瘦身HanaAgent 把模型拆成对话模型、大工具模型、小工具模型、视觉模型这个设计在 Linux 定时任务里非常实用。很多人的 Token 之所以高不是任务多而是所有步骤都用了同一个强模型。下面是一套可落地的分级策略。第一对话模型用便宜档。HanaAgent 的“书桌”便签、心跳巡检、简单分类都可以走轻量对话模型。它只负责判断“这个文件要不要处理”“这个目录有没有变化”不需要写长报告。第二大工具模型只在真正执行时调用。比如“把 inbox 里的 PDF 按日期重命名并生成归档清单”这类任务需要读文件、执行命令、写结果适合用强模型。但前面可以用脚本先做一轮筛选只把新增文件路径给模型不要把整个目录树塞进上下文。第三小工具模型用于检索和摘要。比如从日志里抽取错误、从文件名提取日期、从周报素材里挑重点。它输出短成本低。第四视觉模型只在截图任务里启用。HanaAgent 支持截屏、长截图、网页内容检查但如果你只是整理本地文件夹完全不需要视觉模型。定时任务里把视觉模型设为禁用或者只在特定任务参数里临时启用。心跳降频也很关键。HanaAgent 有“心跳”机制默认可能是高频巡检。如果你让它每分钟扫描一次文件夹模型调用次数会非常夸张。建议改成事件驱动加低频兜底# 高频只跑本地脚本不调模型 */10 * * * * /home/you/bin/local-scan.sh /home/you/hanako-work/logs/scan.log 21 # 低频只有本地脚本发现变化才调 HanaAgent 0 9,12,15,18 * * * /home/you/bin/hanako-cron.sh heartbeat-check /home/you/hanako-work/logs/cron.log 21local-scan.sh可以用find和sha256sum做变化检测#!/usr/bin/env bash set -euo pipefail WORKDIR${HANA_WORKDIR:-$HOME/hanako-work} STATE$WORKDIR/state/inbox.sha256 find $WORKDIR/inbox -type f -print0 | sort -z | xargs -0 sha256sum $STATE.new if ! cmp -s $STATE $STATE.new; then mv $STATE.new $STATE echo changed $WORKDIR/state/inbox.changed else rm -f $STATE.new fi然后 HanaAgent 任务启动前先检查inbox.changedif [ -f $WORKDIR/state/inbox.changed ]; then rm -f $WORKDIR/state/inbox.changed $HOME/bin/hanako-cron.sh daily-inbox fi上下文瘦身还有一个技巧把固定指令放进state/prompt.md每次只传文件清单和路径不传文件全文。HanaAgent 需要读文件时让它在 Bubblewrap 沙盒里按需读取。这样输入 Token 会明显下降。最后周报类任务不要每天全量生成。可以每天只收集素材到state/weekly/周五再让大工具模型汇总一次。素材收集用小模型或纯脚本汇总才用强模型。6. 排障与工具链Claude Code、Codex、CC Switch 配置对照同一台 Linux 上你可能同时用 HanaAgent、Claude Code、Codex。三者只需要共享 Key 和 Base URL配置格式各写各的。Claude Code 用settings.json环境变量走ANTHROPIC_*{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: YOUR_API_KEY } }Codex 用config.toml不要出现ANTHROPIC_*model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chatCC Switch 三件套可以这样组织~/.config/taotoken.env只放 Key权限600。~/.claude/settings.jsonClaude Code 的ANTHROPIC_*配置。~/.codex/config.tomlCodex 的model_providers配置。taotoken.env示例export TAOTOKEN_API_KEYYOUR_API_KEY export TAOTOKEN_BASE_URLhttps://taotoken.net/api在 Cron 或 systemd 里显式加载set -a source $HOME/.config/taotoken.env set a常见报错对照bwrap: Cant bind /etc/resolv.conf改用--ro-bind-try或先确认文件存在。bwrap: Failed to create new namespace检查发行版是否允许非特权用户命名空间不同发行版策略不同按系统文档处理。HanaAgent 日志出现401 unauthorized检查TAOTOKEN_API_KEY是否传入沙盒Base URL 是否为https://taotoken.net/api。任务在终端能跑、Cron 不能跑九成是环境变量和PATH差异用包装脚本显式source环境文件。execvp /opt/hanaagent/hanaagent: No such file or directory应用目录没绑定进 Bubblewrap补--ro-bind /opt/hanaagent /opt/hanaagent。jq: error: Cannot index string with string原始日志不是 JSON先用head看日志格式再决定用jq还是awk。如果你需要更完整的 Claude Code 接法可以看 Claude Code 文档里面写了 Anthropic 风格接口的配置细节。注意文档只用于 Claude Code不要照搬到 Codex。7. 一套可复制的目录结构与落地清单最后给一套 Linux 办公自动化的目录结构直接照着建即可~/hanako-work/ ├── inbox/ # 待处理文件 ├── outbox/ # 结果文件 ├── state/ # 角色卡、技能包、任务模板 │ ├── prompt.md │ └── inbox.sha256 ├── logs/ │ ├── cron.log │ ├── token-ledger.jsonl │ └── daily-inbox-20260829T091000.jsonl └── bin/ ├── bwrap-hanako.sh ├── hanako-cron.sh ├── token-ledger.sh └── local-scan.sh落地顺序从 TaoToken 官网 拿 Key确认 Base URL 为https://taotoken.net/api。把 Key 写进~/.config/taotoken.env权限设为600。在 HanaAgent 模型配置里分别设置对话、大工具、小工具、视觉四类模型便宜模型优先。用bwrap-hanako.sh跑一次手动任务确认沙盒内能看到inbox能访问https://taotoken.net/api。加 Cron 或 systemd user timer但先设成手动触发测试避免一上来就高频消耗 Token。用token-ledger.sh记录第一次任务用量和 TaoToken 控制台对账。观察一周按token-ledger.jsonl的汇总结果调整模型分级和心跳频率。如果你想先试模型效果可以从 模型对话 进如果需要更稳定的编码类额度看 Coding Plan还没创建 Key 就去 API Keys Claude Code 用户直接看 Claude Code 文档。这套方案的重点不是把 HanaAgent 变成全自动黑箱而是让它在 Bubblewrap 的笼子里只碰该碰的目录、只调该调的模型并且每次定时任务都留下 Token 账单。Linux 办公自动化最怕的不是 Agent 不够聪明而是它悄悄跑了一晚上你第二天才发现 Key 被刷爆、文件被改乱。先把沙盒和账本做好再逐步放权才是能长期跑下去的姿势。