架构和远方

我们在落地 Agent 时面临的核心矛盾，是大模型的概率生成机制与工程系统所需的绝对确定性存在天然冲突。要获取大规模、可维护且值得信赖的代码，必须在系统外围构建 Harness。Harness 的本质

如果 AI 能像人一样，随着时间，经验，反馈不断学习，会发生什么？ 我们现在常用的 Agent，不管是豆包，还是编程用的 Cursor，本质是还是一次性对话工程，你问一句，它答一句，或者执行完一堆任务

AI Coding 这件事，我最早听到一个说法：像带着一个实习生干活。 这个比喻当时挺贴切。你得把需求拆细，边界讲清楚，时不时纠偏，还要预防它一本正经地写错东西。后来模型能力明显上来了，这个比喻就开始

在 AI Coding 时代，当我们说提升效能 50%，从老板的角度，那应该要干掉 50% 的人。 但又不能真这么干，这是一个简单的财务逻辑，也是一种本能的反应。 但研发又不是完全标准化的流水线。AI

昨天四十岁。 早上醒来，手机里还是告警、群消息、周报，还是有点超重，腰还是那条腰。 没有什么突然开悟的时刻。 四十岁这件事，落到一个技术人的日常里，大概就是终于承认：很多问题不会因为你讲清楚了道理就消

在 Claude Code 的代码中，如果只算 KAIROS 出现的次数，其出现了 154 次；如果算上以其为前缀的变量啥的，其出现了 365 次。 KAIROS 是什么？ 简单来说，KAIROS 是

最近做 Agent 的同学应该大部分都有研读 Claude Code 泄漏的源码，网上出了各种 AI 加持下的各种解读，教程，细节分析，甚至包括换了一种语言实现的版本，如 Python，Go，Rust

最近在做 Agent 相关的工作，研究了 Claude Code 的系统提示词。分享一下看到的东西。 Claude Code 这套逻辑最值得学习的部分，不是它有多少类型，也不是它怎么写文件，而是它把「

OpenClaw 的 Skills，本质上不是一个「可调用工具」，它更像一套经过约束的运行手册：启动时把技能目录扫描出来，压成一份 <available_skills> 清单塞进 system pro

OpenClaw 是最近 AI 圈最火的一个开源项目，没有之一。 从去年的 Agent 年，到今年的 AI 个人助理，OpenClaw 和去年 Manus 一样的，爆到不行，而且还是开源的版本。 由于

在多 Agent 系统里，上下文怎么传，决定了系统的稳定性上限、成本下限、以及排障时的血压。 最开始，很多团队把它当成「把聊天记录拼一拼」的问题。上线后就会这样的问题： 同样的输入，输出飘得离谱。这里

最近新上了 Opus 4.6 ，它又给我们这帮老程序员上了一课。 在一个近一年没有迭代（指没有被封）的程序员群里，有大佬分享了如下的案例： 那人还剩什么？ 以及这会把程序员的岗位推向哪里。 很多讨论卡

长期记忆不是「把历史对话存起来」。在生产环境里，它更像一套数据管道和检索系统，目标很具体： 让 Agent 在跨天、跨周的任务里保持一致性（用户偏好、项目背景、关键决策不丢）。 让上下文成本可控（To

做 RAG 经常会效果不行，就算是把模型换了更大的，回答依然飘；把向量库换了更贵的，召回还是不稳；把 Prompt 改了很多版，效果依然起起落落。 RAG 的瓶颈大多不在「生成」，而在「检索」。检索做

去年 Vibe Coding 突飞猛进，AI 编程已经逐渐普及。 很多团队对于写代码这件事的定义开始有一些变化。变化在于产出代码的方式：越来越多的代码来自模型，程序员更多时间花在和模型聊天，把问题说清

当 Agent 做到一定复杂度，问题往往不在模型能力本身，而在上下文怎么给、工具怎么给、流程怎么控。同一套模型，有的团队能把它用成「能稳定交付的执行系统」，有的团队只能得到「偶尔灵光一现的聊天机器人」

做 AI Agent，跑起来很容易，简单点函数调用+几个最好的大模型，复杂一点，整合或「学习」一些开源的多 Agent 项目，也能跑起来。 但是如何真正要做到一个行业中去，把一个行业 Agent 做好

2025 年算是 「 AI Agent 元年」。各种 AI Agent 层出不穷，我们能看到的做得比较好的还是编程用的 Agent。 做垂直行业 Agent 最常见的问题是「行业 Know How 没

行业 Agent 和我们常用的「通用聊天 Agent」不是一类东西。 行业 Agent 是要能解决问题的，而查资料只是其中一步，后面还要做判断、走流程、调用系统、校验结果、留痕、可回放。

随着 AI 编程在团队越来越普及，猛然发现一个正在变得「习以为常」的变化：以前遇到问题，第一反应是问同事或 Google；现在第一反应是问 AI。