一个自跑的Agent跑到第32次tick的时候账单刚好停在5.10元。这数字不大但它是我这个“自养Agent”项目第一次真正看到回头钱。熟悉这块的朋友应该能秒懂自养Agent不是说买台服务器扔个脚本就完事从调度触发、日志记录、成本核算到收入落地每一环都得自己兜着。tick32就是第32次定时触发也是我第一次完整地看到这个循环跑通。这篇就当一篇操作日记把tick32这个节点前后的日志细节、成本来源和那个“第一块钱”是怎么回事写清楚。如果你也在养自己的Agent不管是一个定时发消息的小助手还是一个自动整理信息的聚合机器人这篇里关于日志采集、成本统计、问题排查的思路都应该能直接抄作业。我尽量少讲大道理多放可复现的命令、配置和踩坑记录。1. 自养Agent的整体设计与思路拆解先说清楚什么叫“自养Agent”。我这里特指不依赖任何现成低代码平台的、自己从零搭起来的定时任务式智能体自己写调度规则、自己选模型接口、自己写日志、自己处理异常、自己在日志里算账。这么干的原因很简单——只有全链路可控你才知道它每一步在干什么花了多少钱卡在了哪里。这个Agent的用途并不复杂每隔一段时间去抓取一个信息源把抓到的内容交给大模型做整理和摘要再通过消息接口推送给指定对象。整个链路由一个定时器驱动每一次完整执行我管它叫一个“tick”。听起来像是一个非常普通的“抓取生成推送”流水线但真正跑起来之后你会发现日志才是这条流水线的主心骨。很多人一开始容易把注意力放在Agent的“智能程度”上想的是模型怎么选、Prompt怎么调。但以我这32个tick的实际体验来说一个自养Agent能不能长期稳定跑下去日志系统的设计比模型选型更重要。因为模型偶尔抽风是常态定时任务踩点失败也是常态网络抖动、上游接口变更、返回格式飘忽不定这些都是必然出现的。没有一套可靠的日志体系你连它昨天为什么没跑成功都无从查起更别说统计成本了。所以我的设计思路顺序是先确定一次tick要记录什么再定日志怎么写、怎么存、怎么轮转最后才去调模型和Prompt。说白了日志是Agent的“体检报告”没有报告就别谈优化。2. tick机制、日志采集方案与关键配置2.1 tick32是怎么数出来的tick本质就是一次定时触发。我用的调度工具是crontab因为对单机小任务来说它最简单重启不丢任务日志也好定位。我的crontab里配的是每半小时跑一次如果某次失败下一次tick自动补偿检查。tick编号不是crontab给的而是脚本自己在启动时根据日期和运行序号生成的一个自增ID。具体做法是每次tick开始时从本地状态文件里读取上一个tick编号加1之后写入本次运行日志的公共字段。这样一个编号贯穿了这次tick的抓取、模型调用、推送、异常处理全过程。tick32就意味着这个Agent已经成功触发过32次不包括那些因为环境问题根本没起来的情况——没起来的那些会在系统日志层面另行记录。在写日志时每条日志都会带上tick_id、时间戳统一用UTC、事件类型、耗时和错误信息。这样后面无论做成本统计还是问题回溯都可以用tick_id做索引把所有散落的日志快速串起来。2.2 日志格式与落盘方式的选择很多个人项目的Agent日志习惯用print往stdout里一通输出或者用logging默认格式写几行文本。这在最初几天没问题一旦要统计成本和定位问题就会非常痛苦。我建议直接用JSON Lines格式也就是每行一个JSON对象按时间顺序追加到日志文件里。这样既方便人类直接tail看也方便用grep或jq做过滤统计。下面是我实际用的一个Python日志配置精简版import json import logging from datetime import datetime, timezone class JsonFormatter(logging.Formatter): def format(self, record): log_obj { ts: datetime.now(timezone.utc).isoformat(), level: record.levelname, tick_id: getattr(record, tick_id, None), event: record.getMessage(), } if record.exc_info: log_obj[exc] self.formatException(record.exc_info) return json.dumps(log_obj, ensure_asciiFalse) logger logging.getLogger(agent) handler logging.FileHandler(/var/log/agent/agent.log) handler.setFormatter(JsonFormatter()) logger.addHandler(handler) logger.setLevel(logging.INFO)核心思路是结构化字段必须放在顶层尤其是tick_id、level、event这三项。因为后面用jq做统计时jq可以直接按字段过滤。如果你用纯文本日志统计token消耗和调用次数时就得靠正则改一个字段就要改一次正则维护成本太高。落盘方面个人项目不太需要上ELK这种全家桶文件日志加logrotate已经非常够用。如果你正好在用Docker跑Agent建议在Docker的daemon.json里配置好日志驱动参数避免stdout日志无限增长{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这个配置的意思是每个日志文件最大10MB保留最近3个文件。否则一个常驻Agent跑几个月日志文件能把磁盘写满。2.3 cron执行日志怎么查crontab本身不维护自己的事务日志它默认把输出写到邮件或者丢失。最稳妥的方式是在crontab里显式把stdout和stderr重定向到指定文件。举个例子*/30 * * * * cd /opt/agent /usr/bin/python3 run.py /var/log/agent/cron_run.log 21这条命令把每次tick的输出和错误都追加到cron_run.log。注意这里区分两个日志一个是Agent业务日志agent.log一个是调度日志cron_run.log。调度日志记录的是crontab到底有没有把脚本拉起来业务日志记录的是脚本拉起来之后到底发生了什么。排查问题时先看调度日志再进业务日志顺序不能反。很多新手第一坑就是脚本里明明有print但定时执行时看不到任何输出。原因往往是crontab环境变量和PATH和手动执行不一样或者输出重定向到某个不存在的目录。所以看到cron没日志第一反应不是改代码而是先确认crontab里写的那条命令在手动执行时是不是正常工作再确认重定向路径是否有写权限。3. 在日志里抠出成本5.10元是怎么算出来的3.1 为什么每次tick都要记token账一个Agent跑在大模型接口上最大的隐性成本不是服务器而是token。大多数模型计费颗粒度是token数按输入输出分别计价。更要命的是一次tick可能因为重试而调用多次模型接口每次调用都要花一次钱。如果日志里只记录最终结果不记录每次调用的token月底对账时对着账单你会怀疑人生。我的做法是在每次调用模型接口的前后分别记录请求参数和响应结果。响应里通常会有usage字段把prompt_tokens、completion_tokens、total_tokens三个值原样写进日志。注意一定要在日志里区分这是第几次调用因为一次tick里可能有正常调用、失败重试调用、降级调用。举例说明假如一个模型的价格是输入0.001元/千token输出0.002元/千token。某一次调用用了3000个输入token、500个输出token那这次调用的成本就是输入成本 3000 / 1000 * 0.001 0.003元 输出成本 500 / 1000 * 0.002 0.002元 单次成本 0.005元看起来单次只有半分钱但32个tick如果平均每个tick调用两次接口加上部分失败重试成本累积到5.10元非常正常。我统计了一下32个tick一共产生97次模型调用其中成功87次失败重试10次。那10次失败重试里有相当一部分token是浪费掉的因为它们消耗了输入token但没有产生有效输出。这就是为什么成本管理必须从日志开始不能只看最终成功的调用。3.2 用jq从JSON日志里统计成本日志文件是结构化JSON后统计成本就变成了一条jq命令。假设日志里每个模型调用事件长这样{ts: 2025-06-01T10:00:00Z, level: INFO, tick_id: 32, event: model_call_done, prompt_tokens: 3000, completion_tokens: 500}统计总输入token和总输出token可以这样jq -s reduce .[] as $item ({prompt: 0, completion: 0}; .prompt ($item.prompt_tokens // 0); .completion ($item.completion_tokens // 0)) /var/log/agent/agent.log再按不同事件类型分组就可以看出哪些调用浪费了钱。比如把event是model_call_timeout的调用单独拎出来求和你会直观看到网络抖动到底烧了多少钱。我在前32个tick里发现超时重试导致的损耗占总成本大约18%这个比例不能忽略。如果继续养下去我建议每个tick结束时生成一条汇总日志把本次tick的模型调用次数、总成本、成功率写进去。这样后期的趋势分析不用从头扫所有明细日志直接看汇总日志就够了。这也是日志分层的一个小实践明细层做排查聚合层做监控。3.3 那“第一块钱”到底是怎么回事说回标题里那个“第一块钱”。这个Agent在tick32之前一直只有支出没有收入。到了第32个tick我给一个固定的消费场景接了个按次计费的小功能每次成功推送一条整理好的消息并附上来源链接对方按条支付一个极低的价格。第一笔收入就是从这个功能里来的金额是1.00元。这里我不去谈它的商业模式是否性感只想说一个结论从日志数据来看tick32这一天的成本是0.37元收入是1.00元单次tick终于转正了。虽然这点利润连电费都不够但作为一个自养Agent它证明了成本模型是可以跑通的。后面要做的不是盲目加速而是通过日志持续优化每一次的成功率和响应耗时。所以“卡¥5.10”这个描述其实是两个意思。一个意思是累计成本卡在5.10元这个数字上另一个意思是Agent在成本敏感度上开始“卡标尺”——也就是每跑一轮你都得心里有数这轮烧了多少钱值不值。这个意识就是靠日志喂出来的。4. 日志驱动的问题排查与避坑实录4.1 案例一tick没跑完调度日志却显示执行了有一次我检查成本日志发现某个tick的汇总行缺失但cron_run.log里明明有启动记录。后来才发现脚本执行到一半因为外部请求超时直接抛异常退出了。问题就在于我曾经忽略了对未完成tick的标记。解决方法是增加一个“tick开始”事件和“tick结束”事件。每个tick启动时往日志写一行带有tick_id的start事件结束时写一行done事件。这样统计日志时只要查一下哪些tick_id有start没done就能立刻找出夭折的tick。这个思路和分布式系统里的心跳机制一个原理非常简单但极其有效。另外我还给脚本加了一个阶段的超时控制。比如网络请求的统一超时上限是15秒模型调用超时上限是30秒。没有超时控制的话一个tick可能因为一次外部接口挂起一直耗到下一次定时触发造成两个tick重叠日志和计费都会乱掉。4.2 案例二连续失败触发“gameover”保护这个Agent里有一段自我保护逻辑我内部叫它gameover()。含义是如果连续3个tick都出现同一种致命错误就主动停止后续调度不再盲目重试。因为它如果在一个有问题的输入源上反复尝试不仅浪费token还会把所有日志都刷成同样的错误掩盖其他问题。日志在这里起到了闸门的作用。判断逻辑很简单读取最近几个tick的日志看看同一个错误码出现的次数是否达到阈值。达到阈值就写一条event为gameover的日志并在状态文件里标记暂停。第26到第28个tick时它因为上游接口返回格式变化连续失败第28次tick后gameover被触发。我查日志看到那条gameover记录才去检查上游改了字段映射后恢复。这个案例最好的经验是日志不只是给人看的也是给Agent自己看的。Agent可以把自己的历史日志当输入做出“是否需要暂停”的判断。这种自反馈能力才是“自养Agent”比较像“养”的地方。4.3 案例三日志本身成为瓶颈项目跑到第20个tick左右我发现磁盘空间不断告急。一查agent.log已经600MB了。因为我一开始把日志级别设成了DEBUG并且把每次抓取到的原文全文都塞进了日志。这在调试期没问题但稳定运行期就变成灾难。我的调整是给日志级别做区分。抓取到的正文内容不写进主日志文件只记录摘要统计信息真想看正文时通过单独的文件输出并设置logrotate做每日轮转。主日志保持INFO级别结构清晰体积可控。日志轮转配置大致是每天轮转一次保留7天超过7天的压缩归档/var/log/agent/*.log { daily rotate 7 compress missingok notifempty copytruncate }这个配置里需要特别提一下copytruncate它比较适合还在持续写入的日志文件轮转时先复制再清空原文件尽量减少对写入进程的影响。代价是可能会丢极少量的日志尾巴但对个人Agent来说完全可接受。4.4 案例四慢查询和慢日志查询Agent运行过程中需要把推送结果写入一个本地SQLite库。大约在tick30之后我发现在日志中某个查询阶段耗时从几十毫秒涨到两秒多。当时第一反应是不是数据量大了后来通过慢查询日志定位到是某个过滤字段没建索引。给表加上索引后查询耗时回到100毫秒以内。从这个案例里我得到一个通用教训Agent里的每一步耗时都应该记入日志。很多人只记录“有没有成功”不记录“花了多久”。而成本模型里耗时直接影响接口占用和超时风险。后续你再做性能优化没有分步耗时日志就只能靠猜。建议至少记录四个耗时指标抓取耗时、模型调用耗时、数据写入耗时、推送耗时。另外日志文件本身也会膨胀到让查询变慢。当agent.log到了几百MB时即使用jq扫全文件也要几秒钟。这时候可以按天分割日志查询时只针对当天的文件做过滤。不要让一个日志文件无限长分割和轮转必须提前规划。5. 常见问题速查表与配置参考把我在前面32个tick里遇到的问题整理成一个速查表方便照着排查现象可能原因排查方向建议处理crontab到点但脚本没执行调度环境PATH异常查看cron_run.log是否有启动记录在脚本里显式设置PATH使用绝对路径脚本执行但部分步骤没完成外部请求超时搜索对应tick_id的start和done事件增加超时控制和阶段日志日志文件涨得飞快日志级别过低或记录了正文检查单行日志大小、字段内容分级别记录调整logrotate接口失败后不断重试烧钱没有失败阈值保护统计连续失败次数增加gameover式熔断逻辑成本统计对不上账单漏记录重试调用或token字段检查每次模型调用的usage日志确保所有调用路径都写同一格式日志查询日志本身响应慢日志文件过大未分割查看文件大小按天分割启用轮转推送渠道偶尔吞消息没报错接口返回状态码判定过于宽松检查推送回调的完整返回体记录返回码严格判定成功条件这张表里的每一条都是我真实碰过的坑。尤其是“接口失败后不断重试烧钱”这一条非常容易被忽视。因为你往往只看到最终那条成功的结果看不到前面重试了多少次直到月底看账单才吓一跳。而用日志统计重试是唯一靠谱的手段。关于日志脱敏还要补一句因为日志里会包含抓取到的原文内容、消息推送的目标地址等建议在写入前把明显敏感的信息做掩码比如手机号、邮箱、地址长度。这不是说你的日志会被谁看到而是为了避免某一天你想把日志打包发给别人排查问题时发现里面躺着大量不该暴露的数据。个人项目同样要有这个意识。另外时区问题也值得提醒。我的日志统一用UTC时间但crontab用的是本地时区。刚开始对不上时间顺序查了一次早晨没跑的tick发现日志里显示的时间比实际提前了8个小时。后来我规定日志内一律ISO8601带时区偏移调度触发时间单独记录一个local字段。这个习惯救了后面很多次定位问题的效率。关于日志工具选型我目前的结论是个人Agent项目优先用“文件日志 logrotate jq”不要过早引入重型日志平台。只有当你有多个Agent实例或者需要集中检索多台服务器日志时再考虑Loki或ELK。选型的依据是查询频率和日志量而不是技术热度。日志平台本身也是成本也需要维护别让养日志系统的负担超过养Agent本身。6. 写在tick32之后的一点个人体会养了32个tick之后我对“自养Agent”这四个字有了新的理解。它不是你写完代码丢到服务器上就完事而是一个持续打磨的过程。Agent会失败会烧钱会产出乱七八糟的不稳定结果你要做的不是骂它而是通过日志一点点搞清楚它在什么条件下会坏什么条件下最省钱。日志就是你和Agent之间最直接的语言。如果现在让我重新开始这个项目我会把日志系统从第一行代码就放进架构里而不是跑了两周之后才补。tick32只是一个小里程碑5.10元的成本和一个1.00元的收入放在任何商业项目里都微不足道但对一个自养Agent来说它证明了“知道每一分钱花在哪、每一步是怎么走的”这件事本身就是价值。之后每多跑一个tick日志会继续帮我数清楚这轮赚了还是亏了。