敲了15年代码和运维命令，最近折腾AI Agent，突然发觉底层的技术逻辑已经彻底变了

搞了15年架构，我一直是个纯粹的“决定论者”。不管是用 Java、Go 写后端，还是折腾 K8s Ingress 和自研的流水线引擎，我们的世界是极其确定的：你输入 A，经过既定的逻辑，必然得到 B。哪怕中途报了错，翻翻日志，追踪一下堆栈，总能找到那个多加了分号或者配错网段的“罪魁祸首”。系统掌握在自己手里的那种掌控感，是很让人踏实的。

但最近这段时间，这种掌控感被打破了。

业务需要加上个人的兴趣，我近期晚上都在研究本地 AI 框架，用 Go 配合 OpenClaw 做一些 Agent 编排。起初的想法很日常，就是想搞个智能体跑在本地，帮我做点行业方案的检索，甚至顺便帮家里小孩检查下作业。

但在调试这些 Agent 的过程中，我感受到了一种前所未有的“失控感”。

传统的业务系统，出问题我们改代码；但在做大模型接入和 Agent 编排时，结果不符合预期，我们很多时候只能去“炼丹”——调 Prompt，加上下文，或者优化 RAG 的检索策略。你给它同样的输入，它可能因为温度参数（Temperature）的微调，给你返回完全不同风格的结果。

我们以前是在“构建机器”，只要齿轮咬合精确，它就能永远运转；而现在我们更像是在“教导员工”，你得规范它的边界，容忍它的幻觉，并为它的不确定性兜底。

站在架构师的角度，我最近在规划一个算力底座和模型验证平台的方案时，反复在思考一个问题：当应用层的核心逻辑从“确定性的代码”变成了“概率性的黑盒”，我们这些做基础架构、做 CI/CD 和高可用的人，价值到底在哪？

想了很久，或许答案在于“边界的构建”。大模型本身是不可控的，但围绕模型的数据治理、算力调度（比如昇腾等国产硬件的适配）、以及上层业务的安全熔断，这些依然需要极其严苛的工程化手段。我们从“编写核心业务逻辑”，退化成了“为不确定的硅基大脑修建坚固的防爆墙”。

不知道各位干了十年以上的老兵，在从传统业务架构向 AIGC 应用转型的过程中，有没有经历过这种思维方式的阵痛？大家又是怎么去平衡传统工程的严谨与 AI 的模糊性的？

欢迎各位随便聊聊。