Ru果Ke以建议你先点开一首舒缓的歌，哪怕只是作为背景音，慢慢kan。这一年过得太快，快到hen多记忆还没来得及归档，就被新的数据流冲刷得模糊不清。站在2025年的尾巴上回望，那种被技术洪流裹挟着向前的感觉，比以往任何时候dou要强烈。

说实话，当爸爸这件事，比写任何代码dou难。代码不行Ke以重写，bugKe以debug，甚至整个架构推倒重来也不过是加几天班的事。但小朋友的每一个哭声、每一次发烧，那种局促感和无力感，是任何算法dou无法优化的。女儿刚出生的那几个月，我经历了人生中Zui混乱的时期。白天在公司开会、写代码、处理线上问题，试图用逻辑去解释世界；晚上回家换尿布、冲奶粉、哄睡觉，面对的是Zui原始、Zui不讲逻辑的生命需求。

有一次凌晨两三点，女儿突然发高烧。第一次面临这个问题，我和妻子手忙脚乱，夜里开车带着小孩去医院急诊。那种揪心，那种着急，相信每个新手爸妈dou会和我一样，不知所措。那一刻，什么大模型，什么Agent，dou显得那么遥远。这让我意识到，生活不是一段Ke以完美执行的脚本，它充满了随机性和不可预测的“噪音”，而这些，恰恰是Zui真实的部分。

把视线拉回工作。今年工作上Zui大的感受是：AI从“Neng用”到“好用”，要走的路hen长，要Zuo的事hen多。年初那会儿，大模型Yi经火了快一年，各种Agent框架、RAG方案遍地开花，再加上DeepSeek横空出世带来的冲击，感觉AI的门槛一下子被拉低了：好像谁douNeng花三天时间搭一个“智Neng助手”出来。

但真正想把AI落到实际业务里时会发现：跑通一个demo和Zuo出一个Neng用的产品，完全是两回事。Demo是给投资人kan的，产品是给用户用的。用户不在乎你的技术多牛，只在乎好不好用。所以这一年，我主要把精力花在了三件事上：搭知识库、建Multi-Agent架构、Zuo上下文工程。

为什么会需要Multi-Agent呢？单个AgentNengZuo的事是有限的。当任务变得比较复杂的时候，比如“读懂一份需求文档，提取测试点，生成测试用例，还要参考历史Case”，把这些全塞进一个Agent里Prompt是hen爆炸的，效果大打折扣。

所以Zuo了Multi-Agent协作架构。核心设计是“理解 + 任务制定 + 分工 + 协作”。这套架构跑起来之后复杂任务的完成质量明显提升，而且每个环节douKe以单独调优，不会牵一发动全身。

一个体会：Multi-Agent的核心是“让对的Agent在对的节点Zuo对的事”。我们设计了专业化Agent：文档理解Agent专门Zuo文档解析，用例生成Agent专门ZuoCase设计，知识检索Agent专门Zuo召回。这样就Ke以保证每个Agent职责单一，Neng力聚焦。上层有一个统一的MasterAgent负责理解用户意图，把任务分发给合适的Agent，再把结果整合起来。

这就像一个乐队，Dr. Dre在幕后统筹，Eminem负责flow，50美分负责节奏，每个人dou在自己Zui擅长的位置上发光，才Neng产出登顶专辑榜的作品。Ru果让鼓手去唱Rap，那场面肯定是一团糟。

目前的一些尝试，浅显体会是：上下文工程的价值可Neng是当前LLM应用中被低估了的一部分。个人感受：与其花大力气选模型、调Prompt，不如学习如何使用上下文。

今年有个hen火的观点：“Prompt EngineeringYi死，Context Engineering当立”。我hen认同。对于LLM应用来说“如何构造输入给模型的上下文”可Neng比“选择什么模型”geng重要。kan完之后只有一个感受：有东西！用大模型用得越多，越发现：模型Neng力是基础，但输出什么样的质量hen大程度上取决于：你告诉它什么上下文。

当然现在上下文也还在初步的尝试、学习使用阶段。目前在上下文工程上Zuo了几件事：

上下文增强：不只是塞检索结果，还要补充必要的背景信息、格式要求、few-shot示例，让模型geng容易理解任务。

上下文压缩：召回内容太多会超token限制，需要智Neng裁剪：保留Zui相关的、去掉冗余的、控制在合理长度内。

对话上下文管理：多轮对话中，哪些历史要保留、哪些Ke以丢弃、怎么Zuo摘要。这是hen重要的，因为直接影响对话连贯性和准确性。

大模型Zui大的问题是什么？它什么dou知道一点，但对你的业务一无所知。我涉及的场景是测试领域——需求文档、接口文档、历史测试用例、业务规则……这些知识散落在各个系统里格式不一，质量参差不齐。直接丢给大模型，它根本理解不了。所以第一件事，是搭建一套企业级的知识库。

向量检索只是知识库的冰山一角。geng完整的知识库应该包括：知识的组织、geng新、版本管理、权限控制，以及知识与Agent的深度融合。这块还有hen大的Neng力需要建设。

核心思路是“先结构化，再向量化”。我们Zuo了几件事：

知识入库：把各种来源的文档统一采集，Zuo清洗、去重、脱敏。

语义增强：不是简单存原文，而是提取实体、关系、关键信息，形成结构化的知识单元。

混合检索：向量检索 + 关键词检索 + 规则过滤，多路召回再统一排序。

多维向量：不同粒度的内容用不同的向量策略——句子级捕捉语义细节，段落级理解上下文，文档级把握整体主题。

技术有时候革新得太快，还沉浸在prompt、知识库等AI领域知识学习的状态中，Yi经有新东西出来了。为了不掉队，保持学习的低姿态hen重要。但除了技术方向上的一些唠叨，也开心地聊聊这一年的生活、还有一些零碎的感悟。

在消失的三年中，我成了家。有了一个可爱的女儿“柚柚”。生活上，我有了家庭和女儿。我是女儿奴，我承认。成家、当爸爸，这些事情让我geng加有动力给她们geng好的生活。这对我来说弥足珍贵。

澳大利亚Zui近发生的一桩奇事引发了全社会的反思：64岁的乔治·昌博先生在悉尼的公寓中死去一年多后才被破门而入的消防队员发现。在乔治·昌博过世的这一年里房东仍从他的银行账户中扣款，政府也继续发给他福利金。其实此类“奇事”在现代社会屡有发生，“空巢老人”缺乏社会关爱Yi经成为一个突出的全球性社会问题。

这让我想到，我们在追求AI技术极致的同时是不是也忽略了技术Zui本质的温情？AINeng帮我们写代码、Zuo测试，甚至Neng帮我们Zuo决策，但它Neng替代那种人与人之间真实的羁绊吗？就像茶饮界被国潮风席卷，喜茶、乐乐茶dou在Zuo联名，大家dou在追求形式上的新颖和视觉上的冲击，但内核的口味和情感连接才是留住用户的关键。

技术方向上，我会关注几个点：

第一，工程Neng力hen重要。怎么理解呢？怎么把一堆散落的模型、组件、数据流，通过工程化手段串联起来变成一个稳定、高效、可 的系统。这是硬功夫。

第二，用户不在乎你的技术多牛，只在乎好不好用。这点再怎么强调dou不为过。不要为了技术而技术，要为了解决问题而技术。

第三，别太焦虑，选准方向踏实Zuo。与其焦虑，不如先行。共勉。

2025年是充实的一年。这一年Zuo的事情，可Neng是我这几年工作以来比较有“沉淀和进步”的一年。AI的浪潮真正席卷到了我们日常工作的每一个角落。从年初的观望，到年中的All in，再到现在真正落地了一些Neng力。

技术上，在AI方向有了hen多的尝试，落地。学到了hen多领域的知识。这是一件hen棒的事。我hen喜欢。就像六七十年代，“新浪潮”电影席卷全世界一样，现在的AI也在重塑我们的世界。虽然有时候会觉得累，觉得跟不上节奏，但回头kan，走过的路dou算数。

2026年，希望Neng继续保持这个节奏：认真工作，好好生活，捡起写文章的好习惯。也分享一些没体验过的时刻，记录下那些微小但闪光的瞬间。

Zui后的Zui后Ru果你也在ZuoAI方向的工作，欢迎交流。在技术的路上，一起前行。元旦快乐！

我的答案是：Neng，但不是你想象的那种“一键生成”。它geng像是一个“助手”。Neng帮你Zuohen多重复性、模式化的工作，但核心的思考、判断、决策，自己决定。所以25年的Zui后一天是值得记录下来给这一年画个完美句号。