容器随时会死,但两小时的进度不该跟着死
Agent 沙盒系列第四篇。把进度从容器的内存里搬到一块共享硬盘上,然后当场删掉正在干活的容器——换一个容器接着从第 17 页往下跑。也照实说清楚:这一步的"自动恢复"其实还得人工点一下。
- Kubernetes
- AI Agent
- 容错
学习过程中的技术笔记与原创文章:商业分析、MBSE、知识工程,以及 AI 工具的实际用法。
Agent 沙盒系列第四篇。把进度从容器的内存里搬到一块共享硬盘上,然后当场删掉正在干活的容器——换一个容器接着从第 17 页往下跑。也照实说清楚:这一步的"自动恢复"其实还得人工点一下。
Agent 沙盒系列第三篇。温池就是"机场排队等客的出租车",快是快了,但空车也在烧油。这一篇也照实写出这版调度写得不好的三个地方——它们正是后面几篇的起因。
Agent 沙盒系列第二篇。一任务一容器听起来理所当然,代价是用户提交后要等 45 到 90 秒。这一篇拆开这几十秒到底花在哪,以及为什么"管理系统的接口"不能放在用户点击的那条路上。
Agent 沙盒系列第一篇。让 AI 帮你连续跑两小时的活,为什么"能跑通"和"能上线"之间差着一道隔离?用一个会被系统强制杀掉的小服务做基线,把问题看清楚。术语都有解释,不熟悉 Kubernetes 也能读。
把 Ontology、知识图谱、数据库 Schema、工作流、Agent 的边界一次划清楚,并说明我的判断——企业不该自上而下建全局本体,而应该由 Agent 被允许执行的动作倒推着建。
整理公开资料后我的判断是,Glean 值钱的地方不是搜索做得好,而是它把「谁能看什么」这件苦活做完了。也顺手记下我对长上下文淘汰 RAG 这个说法的看法。