昨晚十点多公司领导和技术负责人加上我们几个做 Agent 开发的同事聊了不到一小时。说是讨论其实大部分时间都是老板和技术负责人在给我们分享经验。他们讲完的那一刻我有一种很强的冲击感——不只是技术层面的收获而是一种看待问题的角度被刷新了。今天把其中最有价值的一些观点写下来希望对正在做 Agent 开发的朋友也有用。你到底是后端工程师还是 Agent 工程师这是昨晚最直击灵魂的一个问题。技术负责人说了一句话我到现在还在反复琢磨“大家是 Agent 开发工程师不是后端工程师。”他观察到团队在开发过程中满脑子都是前端逻辑、后端逻辑、数据流、接口调用。但在他的视角里这些东西不是那么地重要。最重要的只有一个Agent 的表现好不好。不是说前后端不重要而是你的思考原点不能停留在那里。如果你开发一个功能只关心代码能不能跑通、接口能不能调通那你做的就是一个普通的 CRUD 功能。但如果你开发的是给 Agent 用的功能你得关心的是——Agent 用得舒不舒服。我开发的时候也有这种感觉。有时候看 Agent 在执行任务它明明能完成任务但绕了一大圈路走得很别扭。我站在它的角度去想会觉得它很难受。这不是玄学这是一种体感。当 Agent 走得很顺的时候它的效果自然就好当它半路卡一下、那里绕一下效果就差。所以核心问题不是「这个接口对不对」而是「Agent 看到这个东西的时候它会不会困惑」。大模型是你的甲方不是你的工具这是老板提出的观点也是昨晚第二个让我醍醐灌顶的观点。很多人认为我们的产品服务用户而大模型只是产品的一部分。但老板说这个关系完全搞反了。正确的逻辑是我们在给大模型提供服务大模型给用户提供服务。用户面对的不是我们的产品而是那个大模型。大模型能不能服务好用户取决于我们作为它的「供应商」能不能提供好的基础设施。这就像开演唱会。你要请一个明星来表演还要请观众来看。你的工作是搭建一个场馆——让明星唱得舒服让观众看得舒服。明星是谁是大模型。 观众是谁是用户。 场馆是什么是我们搭建的整个系统。如果你只注重场馆的座椅够不够软用户体验但明星在台上唱得很不舒服Agent 执行不顺畅那最后这场演出不会成功。这个视角的差异决定了你思考的原点是完全不同的。拿到需求之后先拆解老板讲了很多高屋建筑的东西但落到执行层面我觉得最实用的一个方法是拿到需求后第一件事不是写代码而是拆解。第一步想清楚用户要实现什么目标。不是「这个功能是什么」而是「用户做完这件事之后他得到了什么」。第二步拆解成更小的功能模块。因为一口气全部动工前面还没做好后面的问题就来了问题叠加起来根本定位不了。第三步也是最关键的一步——用二分法把所有东西分成两类哪些是暴露给大模型的哪些不是。暴露给大模型的是 Agent 能看到的上下文。不暴露的是纯粹的底层逻辑。老板说他和技术负责人讨论任何需求第一件事就是做这个二分先把跟大模型无关的东西全部拿掉然后再看剩下的部分今天要改的东西到底是改了一个末梢神经还是动了主干神经。这个思维框架一旦建立起来你的开发就会变成你的经验。什么是真正的经验老板问了大家一个问题我觉得值得每一个技术人员思考你能不能在没有充分证据的情况下产生自己的判断他把这个叫做经验。不是「我做过什么」而是「如果今天让我做这个东西我觉得效果会变好还是变差」。前者是客观经历它在不断贬值。因为工具越来越强你以前踩过的坑可能已经被框架解决了。但后者——判断和假设的能力——价值会越来越高。而且预判地对不对不重要。重要的是一定要有预判。没有预判你就没法通过开发来积累真正属于自己的语料。你只是在机械地完成功能。你可能做了一两年但是依旧在原地踏步。老板说他把任务整合、写需求、记录改动的过程看得很重不是因为要给大家提格式化的要求而是因为写东西的过程本身就是思路的梳理和预设。这个我深有体会。写的过程不是单纯地码字而是把框架、把思路理顺。背景描述和方案写清楚了你才能看到自己哪里想得不够透。所有功能都不是孤立存在的做 Agent 开发和传统开发有一个很大的区别你加的任何功能都会影响到整个系统。就像人吃药一样。青霉素肯定是有用的但青霉素过敏致死的案例也发生过。你加一个功能它可能和已有的机制产生协同也可能产生排斥。所以每做一个东西都要想清楚它的边界这个东西对主干有没有影响还是只对某个分支有影响或者只影响分支里的某一个特殊情境就像人脑的神经网络不是每一个神经都至关重要但一定有那么几个关键神经。切断了和大脑的连接你会失去记忆。切断了左右脑的连接你的身体会不协调。我们在给大模型提供的整套「牵引机制」里也是有主次之分的。你要知道今天改的这个东西到底改的是末梢神经还是主干神经。把大模型当人看这是昨晚讨论让我最有共鸣的一个角度。虽然我们都很清楚大模型不是人但人的沟通能力是天生就会的吗一个被狼养大的小孩他能和人沟通吗不能因为他没有被语言模型训练过。所以本质上语言沟通不是人与生俱来的能力而是通过共同的范式不断训练和强化出来的。大模型通过海量的人类语料被训练出来它在沟通层面至少是可以被当作人一样去带入的。那代入他的视角就变成了一件非常重要的事。比如全局命名一致性。你的系统里面有 SA、TA 这样的缩写。TA 在营销领域是 Target Audience在游戏领域是 Technical Artist在其他领域还有别的含义。大模型看到 TA 这个字段的时候它会不会混淆它怎么知道系统提示词里的 TA 跟用户上下文里的 TA 是不是一个意思就这一个细节去年春节的时候他们还在加班解决。所以当你去开发一个 Agent 功能的时候多问自己一句大模型能看到什么如果它看不到的东西你不需要操心。如果它能看到你就得替它想清楚它会不会困惑。预判是 Agent 开发者的核心能力最后聊聊行业。老板说他最近面试了很多人10 个大概 pass 掉了 9 个。因为绝大多数做 Agent 的工程师只是觉得这个方向比较火看了一些技术公众号或者开源项目做了一个客服 Agent 或者旅游 Agent就觉得会了。但有一个最根本的问题他们从来没有好奇过大模型在接下来 6 到 12 个月会在哪个方面有重大突破这不是一个务虚的问题而是一个非常务实的预判。就像给小孩做衣服你不能等他穿不下了再去做。你得提前想他半年后会长多高会在什么场景下穿什么样的衣服。在这个行业跟在别人后面是追不上的。你必须连续预判大模型的下一个路口在哪。压对一次可能不够——模型一升级竞品两周三周就追上来了。你得连续压对产品才能持续领先。当然我作为一个刚入门不久的开发者离这种预判能力还差得很远。但至少我知道了努力的方向不是学更多的框架、调更多的接口而是去理解大模型本身去培养对它的体感。最后老板说了一句话我深以为然如果一个团队因为产品的功能而没有提升自己团队的水平那你只是在帮竞品做 MVP拿了钱就走人了。只有团队在功能的演化过程中变得越来越强你才能真正拿得住产品守得住市场。所以下次拿到需求的时候先别急着写代码。先问自己三个问题这个功能大模型能看到吗它用了会不会舒服它对我的整个系统是改了末梢神经还是主干神经想清楚了再动手。比写代码更重要的是你写代码之前的判断。写文章最开心的事就是有人读了觉得有用。如果今天的内容帮到了你点个关注、点赞收藏就能让我知道——下篇继续聊干货。/ 作者Kakarot / 投稿或爆料请联系邮箱19331922086163.com
