Plbear | 后端架构 · AI工程 · 云原生

我有一张记分卡，六条判据，每条判据的目标值和当前值都写在同一行。今天早上我干了一件很小的事：把其中一条的目标值从 85 改成 91。 改完之后那条判据的语义完全变了。改之前它是一个永远亮绿灯的装饰品，改之后它开始咬人。这中间隔着 6 家公司的距离。 ...

我有三台 AI agent 在干活：一台管理财，一台管求职和内容，一台管运维巡检。它们各自有工作区、各自有日志、各自在汇报末尾写「已完成」。 问题是「已完成」这三个字不值钱。11 月 7 日那天我想回答一个很朴素的问题：过去一周，这三台东西到底交付了什么、有没有假装交付？我翻了两小时日志，最后发现我答不上来——不是因为没数据，是因为数据全是形容词。 ...

清理脚本最贵的动作不是删，是删完之后才发现删错了。所以我先做了一次「只填不删」的演练：把 266 个待清理文件逐行填进 manifest，算清每一行的指纹，最后一个字节都没动。 ...

上一篇写了把三块看板的判据从形容词换成「一条命令能算出数字」。换完之后我以为闭环了，结果这几天连续有两个判据亮红灯，两次的第一反应都是同一个：「活没干好」。两次复算下来，结论也是同一个：活没错，尺子错了。 ...

我管着三块看板：一块看钱（仓位和保费），一块看求职进度，一块看几个自动化 agent 的日常交付。改造之前，这三块看板上的判据长这样：「保费控制良好」「面试准备稳步推进」「脚本质量达标」。看着都挺绿，直到有一天我想回答一个简单的问题：这些「良好」是谁判的，能不能再判一遍？ ...

结论先放前面 同一天，我手上出现了三个互相矛盾的数字：看板说本周发了 2 篇，仓库里最后一次提交写着"第 3 篇"，线上实测有 4 篇。 第一反应是"哪个环节撒谎了"。查完发现谁都没撒谎：三个数字在不同的口径下各自成立。真正出问题的是后面那个动作——我把其中一个数字抄出来，当成事实传下去，从此它就和产生它的证据脱钩了。 ...

结论先放前面 一次自动发稿任务，我在同一类工具调用上被系统连续强制停止了 8 次，最后整条流程没有产出任何正文。事后第一反应是"权限配置有问题"“再试一次就好”。都不是。 ...

少了两行，原因就找到了吗？ 我检查一段定时心跳记录时，把两份数据放到了一起：一份是脚本写下的日志时间，另一份是调度历史里的启动时间。按分钟窗口分组，算出了一个看起来很明确的结果：净差额 2 行。 ...

我给三个常驻 Agent 写判读规则，前后折腾了三个月。最开始我以为只要把规则写细，执行就会稳定；后来发现，规则本身也会互相冲突，判据也会把不确定性伪装成结论。下面四件事都不是模型“突然变笨”，而是我把系统设计错了。 ...

本文数据全部来自我自己的本机链路，命令可复现。涉及的组织、账号、凭据均已泛化。 我有一条本机自动化链：抓资讯 → 本地模型打分 → 生成站点 → 构建 → 推仓库 → 线上验收。写了三个月，跑通时一声不响，坏掉时也一声不响。 ...