说实话我自己的第一个生产级 Agent上线第一天就被打回了原型。那会儿我刚把 Harness 搭好的 Agent 服务部署到测试环境自我感觉良好——能跑通、能完成任务、日志也打了。结果运维同学看了一眼就问我挂了怎么办谁重启资源超限了有没有告警Token 花爆了谁来赔我愣在原地一个问题都答不上来。后来我花了整整三天才把那个玩具变成一个勉强能扛生产的东西。今天就把我自己踩过的坑还有最终沉淀下来的 checklist从头到尾捋一遍。你照着走一遍至少不会像我一样上线第一天就被运维怼回来。先说一个最容易被忽略的事——可观测性Observability。你写 Agent 的时候在终端里跑什么都能看到。但是部署到服务器上你连它死在哪儿都不知道。我第一次跑的时候Agent 默默执行了六个小时然后什么都没输出——我以为它卡住了强行 kill 了进程结果发现它其实已经完成了只是最后一步写结果的回调里有个 bug日志没刷出来。所以你的 Agent 上线之前至少要做到三件事日志打到文件、关键节点打埋点、每次任务结束打一个 summary 日志。Harness 本身有logger对象用起来就行。别偷懒别觉得我盯着看就行——你会被其他事情打断的你一定会。笑死我后来还加了一个心跳日志每 30 秒打一行[heartbeat] running...这样至少能知道它是不是还活着。听起来很蠢但真的救过我的命。再说资源控制。这个坑特别深。Agent 跑一个任务你可能觉得几分钟的事——但生产环境里一个任务可能跑几个小时甚至过夜。如果不设超时它可能一直跑下去把你的 API 配额吃光。我踩过的坑是Harness 的max_iterations参数默认是 100对于复杂任务根本不够但你不设上限又不行。我的做法是分两层控制。第一层在 Harness 配置里设max_iterations为一个合理的上限比如 500。第二层在应用层再加一个 wall clock timeout实际运行时间超时比如 2 小时。两层任何一个触发就终止任务并记录原因。还有内存。Agent 跑久了上下文会越积越多。你设的max_tokens只是模型生成的上限不代表 Agent 的内存占用。我有个任务跑了 40 分钟OOM内存溢出了——因为每轮迭代都把历史对话 append 到列表里从来不清理。后来我加了一个滑动窗口只保留最近 20 轮交互内存直接降了 70%。说到钱Token 成本这事你不提前管月底账单会教你做人。我有个同事把 Agent 丢到生产环境一周后收到 Cloud API 的账单——$800。他当时脸都绿了。后来一查有个任务进了死循环Agent 不停地调模型每轮都花 1 万 token一晚上跑了 300 轮。你别说这事儿太容易发生了。所以上线前必须做三件事每个任务设 token 预算上限、每次调用记录 token 消耗并累加、超出预算直接终止。Harness 的token_limit参数可以设全局上限但更细粒度的控制需要你自己写一个中间件或者插件来做。还有一点你可能想不到——把模型换成便宜的版本做测试。你在开发的时候一直用 GPT-4 或者 Claude Sonnet调试一个 bug 可能花掉几十万 token。我后来习惯写一个--dry-run模式用 Harness 的 Lite 模式或者 DeepSeek 跑测试只有确认逻辑没问题了才切回主力模型跑正式任务。有个事我必须单独拎出来说——错误处理和重试机制Retry。Agent 在开发环境里API 调用几乎不会失败。但生产环境不一样。网络抖动、API 限流、模型服务降级——什么破事都能碰上。我第一次上线的 Agent遇到 429Too Many Requests就直接崩了没有任何重试逻辑。你猜怎么着那个 Agent 上线后的第一个周末API 服务商做了一次灰度升级限流策略变了我的 Agent 直接躺了三天等周一上班才发现。所以一个生产级的 Agent必须内置重试逻辑。指数退避exponential backoff是标配第一次失败等 1 秒第二次 2 秒第三次 4 秒最多重试 5 次。Harness 的插件系统里可以写一个retry_plugin来统一处理。另外重试所有次数都失败之后一定要发告警——发到飞书群、钉钉群、或者邮件总之不能悄无声息地死掉。最后说一个很多人到了生产环境才意识到的问题——敏感信息泄露。Agent 在执行任务的过程中可能会把 API Key、数据库密码、内部 URL 这些东西写到日志里、写到模型输出里、甚至写到文件里。你写的 prompt 可能不小心包含了敏感信息模型在回答的时候可能把整段配置吐出来。我有个惨痛教训调试的时候我把一个内部服务的连接字符串写在了 prompt 的 system message 里然后在测试的时候问模型你看到了什么模型把整个连接字符串原样输出了——还好是测试环境要是生产环境这就是一次安全事件。所以上线前的最后一步写一个日志扫描器或者用 Harness 的output_filter功能把敏感信息在输出之前过滤掉。至少要做到不把 API Key 写死在代码里、不用 prompt 传敏感信息、日志里打码处理。你发现没有上面说的这些没有一个是Agent 能不能跑的问题——全都是跑起来之后怎么办的问题。造一个能跑通任务的原型可能只需要两个小时。但让它能稳定地跑在生产环境上每天处理几百个任务不崩溃、不超支、不漏数据——那才是真正的修炼。我到现在还在踩坑还在改自己的 checklist。你觉得你在生产环境里踩过最离谱的坑是什么欢迎评论区说说我也学学。
说实话我自己的第一个生产级 Agent上线第一天就被打回了原型。那会儿我刚把 Harness 搭好的 Agent 服务部署到测试环境自我感觉良好——能跑通、能完成任务、日志也打了。结果运维同学看了一眼就问我挂了怎么办谁重启资源超限了有没有告警Token 花爆了谁来赔我愣在原地一个问题都答不上来。后来我花了整整三天才把那个玩具变成一个勉强能扛生产的东西。今天就把我自己踩过的坑还有最终沉淀下来的 checklist从头到尾捋一遍。你照着走一遍至少不会像我一样上线第一天就被运维怼回来。先说一个最容易被忽略的事——可观测性Observability。你写 Agent 的时候在终端里跑什么都能看到。但是部署到服务器上你连它死在哪儿都不知道。我第一次跑的时候Agent 默默执行了六个小时然后什么都没输出——我以为它卡住了强行 kill 了进程结果发现它其实已经完成了只是最后一步写结果的回调里有个 bug日志没刷出来。所以你的 Agent 上线之前至少要做到三件事日志打到文件、关键节点打埋点、每次任务结束打一个 summary 日志。Harness 本身有logger对象用起来就行。别偷懒别觉得我盯着看就行——你会被其他事情打断的你一定会。笑死我后来还加了一个心跳日志每 30 秒打一行[heartbeat] running...这样至少能知道它是不是还活着。听起来很蠢但真的救过我的命。再说资源控制。这个坑特别深。Agent 跑一个任务你可能觉得几分钟的事——但生产环境里一个任务可能跑几个小时甚至过夜。如果不设超时它可能一直跑下去把你的 API 配额吃光。我踩过的坑是Harness 的max_iterations参数默认是 100对于复杂任务根本不够但你不设上限又不行。我的做法是分两层控制。第一层在 Harness 配置里设max_iterations为一个合理的上限比如 500。第二层在应用层再加一个 wall clock timeout实际运行时间超时比如 2 小时。两层任何一个触发就终止任务并记录原因。还有内存。Agent 跑久了上下文会越积越多。你设的max_tokens只是模型生成的上限不代表 Agent 的内存占用。我有个任务跑了 40 分钟OOM内存溢出了——因为每轮迭代都把历史对话 append 到列表里从来不清理。后来我加了一个滑动窗口只保留最近 20 轮交互内存直接降了 70%。说到钱Token 成本这事你不提前管月底账单会教你做人。我有个同事把 Agent 丢到生产环境一周后收到 Cloud API 的账单——$800。他当时脸都绿了。后来一查有个任务进了死循环Agent 不停地调模型每轮都花 1 万 token一晚上跑了 300 轮。你别说这事儿太容易发生了。所以上线前必须做三件事每个任务设 token 预算上限、每次调用记录 token 消耗并累加、超出预算直接终止。Harness 的token_limit参数可以设全局上限但更细粒度的控制需要你自己写一个中间件或者插件来做。还有一点你可能想不到——把模型换成便宜的版本做测试。你在开发的时候一直用 GPT-4 或者 Claude Sonnet调试一个 bug 可能花掉几十万 token。我后来习惯写一个--dry-run模式用 Harness 的 Lite 模式或者 DeepSeek 跑测试只有确认逻辑没问题了才切回主力模型跑正式任务。有个事我必须单独拎出来说——错误处理和重试机制Retry。Agent 在开发环境里API 调用几乎不会失败。但生产环境不一样。网络抖动、API 限流、模型服务降级——什么破事都能碰上。我第一次上线的 Agent遇到 429Too Many Requests就直接崩了没有任何重试逻辑。你猜怎么着那个 Agent 上线后的第一个周末API 服务商做了一次灰度升级限流策略变了我的 Agent 直接躺了三天等周一上班才发现。所以一个生产级的 Agent必须内置重试逻辑。指数退避exponential backoff是标配第一次失败等 1 秒第二次 2 秒第三次 4 秒最多重试 5 次。Harness 的插件系统里可以写一个retry_plugin来统一处理。另外重试所有次数都失败之后一定要发告警——发到飞书群、钉钉群、或者邮件总之不能悄无声息地死掉。最后说一个很多人到了生产环境才意识到的问题——敏感信息泄露。Agent 在执行任务的过程中可能会把 API Key、数据库密码、内部 URL 这些东西写到日志里、写到模型输出里、甚至写到文件里。你写的 prompt 可能不小心包含了敏感信息模型在回答的时候可能把整段配置吐出来。我有个惨痛教训调试的时候我把一个内部服务的连接字符串写在了 prompt 的 system message 里然后在测试的时候问模型你看到了什么模型把整个连接字符串原样输出了——还好是测试环境要是生产环境这就是一次安全事件。所以上线前的最后一步写一个日志扫描器或者用 Harness 的output_filter功能把敏感信息在输出之前过滤掉。至少要做到不把 API Key 写死在代码里、不用 prompt 传敏感信息、日志里打码处理。你发现没有上面说的这些没有一个是Agent 能不能跑的问题——全都是跑起来之后怎么办的问题。造一个能跑通任务的原型可能只需要两个小时。但让它能稳定地跑在生产环境上每天处理几百个任务不崩溃、不超支、不漏数据——那才是真正的修炼。我到现在还在踩坑还在改自己的 checklist。你觉得你在生产环境里踩过最离谱的坑是什么欢迎评论区说说我也学学。
