一句话总结
你不是在"学习Agent框架"，而是在用90天完成一个残酷筛选：证明你能独立定义"什么值得做"，而非等待别人给你正确答案。
适合谁看
画像一：刚拿到offer的AI工程师，还没进组
你坐在新工位上，第一周就被拉进一个Agent项目评审会。PM说"我们要做一个能自动处理客服工单的多Agent系统"，技术负责人接话"用LangChain搭一下，两周上线"。你点头，但心里没底：LangChain是答案吗？还是只是最先被说出来的的那个？你打开GitHub，发现组里已经有一个半成品的repo，但README写的是三个月前的架构，代码里到处是# TODO: refactor this hack。你不知道该问谁，因为隔壁资深工程师的日历已经排到两周后。这篇文章就是给你这种人的：不是教你"怎么学"，而是告诉你"在这个阶段，什么判断是对的，什么是大概率会让你踩坑的"。
画像二：正在面试AI岗、想提前理解团队运作逻辑的人
你在准备某大厂的AI工程师面试。面试官问你"设计一个多Agent协作系统"，你背了一套ReAct框架的定义，面试官点点头，然后追问："如果两个Agent对同一个用户请求给出了矛盾的回答，你作为工程负责人，怎么处理？"你愣住了——这不在任何八股文里。这篇文章的价值在于：它把面试题还原成了真实的团队决策场景，让你理解"面试官到底在考察什么判断能力"，而不是"正确答案是什么"。
画像三：从传统软件工程转AI工程，带着"确定性思维"的人
你过去五年写的是后端服务，接口定义清晰，单元测试能覆盖90%分支。现在你要面对的是一个"Agent连自己的输出都不完全可控"的世界。你的直觉是"先写死规则，把不确定性降到最低"，但这个判断在AI工程团队里往往是错的——不是规则本身错，而是时机错。你需要先理解"什么时候该容忍不确定性，什么时候必须收紧"，这篇文章会反复回到这个核心判断。
核心内容
你不是在"学框架"，而是在通过框架理解团队的决策逻辑
大多数新人在前90天犯的错误是线性的：看到团队用LangGraph，就去刷完官方文档；看到同事提到"我们用的是Plan-and-Execute"，就把论文打印出来做笔记。这个动作本身没错，但它隐藏了一个危险的假设——"我懂了框架，就懂了团队为什么选它"。
真实的团队决策从来不是这样的。
我经历过一个具体场景：新入职的工程师Alex（化名，下同）在第一周就问我"为什么我们用LangGraph而不是CrewAI？CrewAI的社区更活跃"。我让他去问了三个问题：第一，我们半年前选型时的核心约束是什么；第二，当时评估过哪些框架，否决理由分别是什么；第三，现在回头看，哪些否决理由已经过时了。Alex花了两天时间，翻出了当时的RFC文档和Slack线程——结论是，选型时CrewAI还不支持我们需要的条件分支逻辑，而LangGraph的图结构恰好匹配了当时一个关键客户的定制化需求。但更重要的是，团队已经在三个月前意识到LangGraph的过度抽象带来了调试困难，正在逐步把核心逻辑迁移到更轻量的状态机实现上。
这个信息对Alex的前90天至关重要。
他不是"学会了LangGraph"，而是理解了一件事：团队的技术栈是一个活的历史文档，不是静态的正确答案。 你的任务不是成为某个框架的专家，而是快速定位到"哪些决策是刚做的、还在讨论中的，哪些是老旧的、需要被挑战的"。前90天你最该做的判断是：这个框架的哪些部分正在被团队主动弱化，而不是强化。
另一个反直觉的观察：答得最好的人，往往第一个被筛掉。 我见过太多新人在技术讨论会上滔滔不绝地分析"为什么ReAct比Reflexion更适合这个场景"，引用论文、对比指标、给出实现细节。但资深工程师的反馈通常是中性的："嗯，研究得很细。" 然后就没有然后了。问题出在哪里？你把"知道"当成了"判断"，把"分析"当成了"决策"。 团队真正想听的是：基于我们现在的资源约束和业务目标，这个框架的哪个具体特性会让我们更快交付，或者更快暴露风险？"更快暴露风险"比"更快交付"更重要，因为AI工程的最大成本往往是晚发现的问题。
"不是A，而是B"：三个你大概率想错的判断
不是"先搞懂技术栈再做事"，而是"先用一件事倒逼自己搞懂技术栈"
新人常问："我应该先花两周把组里的Agent框架代码全看一遍吗？" 我的判断是：不。你应该在入职第一周就主动认领一个具体的、有截止日期的任务——哪怕是修复一个Agent输出格式不稳定的bug，或者给现有的单Agent系统增加一个异常重试机制。这个任务的价值不在于它本身有多难，而在于它会强迫你与代码、与文档、与同事的对话发生真实的摩擦。
我管过的一个新人，入职第三天就被我"推"去处理一个客户反馈：我们的客服Agent在特定场景下会循环调用同一个工具，直到超时。他没有先去"系统学习"代码结构，而是直接拉了日志，发现是工具描述（tool description）的模糊性导致LLM在每次决策时都倾向于选择同一个"看起来最安全"的工具。他在两天内给出了一个修复：不是重写工具描述，而是在Agent的决策层增加了一个简单的"最近N步已用工具"的记忆检查。这个方案后来被团队采纳为标准实践。他在第五天就建立了"我能独立解决这里的问题"的信任，而不是在两周后才"准备好"。
不是"框架选对了就成功了一半"，而是"框架的废弃策略比选型更重要"
我见过太多团队在All Hands上大谈"我们为什么选择AutoGen"，但从来没有文档记录"什么条件下我们会放弃它"。前90天的关键判断是：这个团队有没有为当前框架定义退出条件？ 不是"我们会一直用下去"这种空话，而是具体的：如果框架的某个核心指标（如调试平均耗时、新成员上手时间）超过阈值，替代方案是什么，谁有权启动迁移？
一个真实的细节：我现在的团队在LangGraph还只有0.1版本时就引入了它。当时的决策文档里明确写了一条——"如果图的执行可视化调试在两个月内没有改善，我们将回退到基于纯Python状态机的实现，预计重写成本是3人周"。这个条款从未被触发，但它存在的事实改变了团队的讨论方式：大家不会把LangGraph当成"我们要维护十年的基础设施"，而是"当前最优的临时方案"。你的前90天任务之一，就是找到或推动建立这种"健康的临时感"。
不是"向资深工程师学习最佳实践"，而是"观察他们正在回避什么"
这是最反直觉的一点。新人倾向于把资深工程师的行为等同于"正确做法"，但更有价值的观察是：他们在哪些场景下选择了不做、不说、不优化？
举个例子：我们的技术负责人在代码评审中经常拒绝把Agent的prompt优化到"完美"——即使测试用例显示还有提升空间。他的原话是："这个prompt现在够用了，优化到95%的边际收益抵不上它变得不可维护的风险。" 这不是懒，而是一个关键判断：AI工程的核心矛盾不是"做不够好"，而是"不知道什么时侯该停"。 你在前90天应该做的，是记录这些"停下来的时刻"，理解背后的约束条件（时间、人力、可解释性要求），而不是盲目复制他们"做了的"那些部分。
具体场景：debrief会议、跨部门冲突、hiring committee的真实细节
场景一：debrief会议——"这个Agent方案为什么延迟了两周？"
我刚入职第二个月，参加了一个项目延期debrief。表面原因是"LLM API的延迟波动导致整体响应时间不可接受"，但会议的真正价值在于观察不同角色的归因方式。PM倾向于把问题定义为"需要更好的SLA保障"，提议增加重试和缓存；技术负责人看到的是"我们的Agent架构假设了同步调用，但长任务本质上更适合异步处理"；而VP of Engineering只问了一个问题："如果重来一遍，我们在哪个时间点能发现这个风险？"
这个会议教给我的不是技术方案，而是"什么时候该把问题升级，什么时候该在本地解决"。 前90天的你要做的判断是：在这个团队里，"延迟"是一个技术问题、产品问题，还是组织沟通问题？答案决定了你下次遇到类似情况时，应该拉谁进讨论、在什么阶段。
场景二：跨部门冲突——搜索团队说"你们的Agent把我们的API配额打满了"
这是一个典型的资源冲突。Agent团队的新功能需要大量调用搜索API，而搜索团队有自己的稳定性指标。新人常见的反应是"我们去谈判，争取更多配额"或者"我们优化调用频率"。但当时的 senior engineer 做了一个不同的判断：他提出的是"我们能不能定义一个'搜索必要性'的内部评分，低必要性的查询直接走缓存或简化版答案，只把高必要性查询发给搜索团队"。
这个方案的关键在于，它没有试图"解决"冲突，而是重新定义了协作的接口。 前90天的你要理解的是：在这个组织里，跨部门问题的默认解决路径是"谈判资源"还是"重构接口"？这个判断会直接影响你未来的工作方式。
场景三：hiring committee讨论——"我们要不要招一个纯研究背景的候选人？"
我作为旁听参与过一场HC讨论，候选人是某顶会一作，论文引用量很高。支持方说"我们需要这种深度来优化我们的Agent推理链"，反对方说"他从来没有在production环境里迭代过，我们的问题是工程可靠性不是算法创新"。最终没有发offer。
这个决策背后的判断是：团队当前阶段的核心瓶颈是什么？ 不是"研究能力不重要"，而是"这个能力现在引入的边际收益低于它带来的协作成本"。前90天的你，应该通过观察这类讨论，反向推导出"我现在最该补强的能力是什么"——如果团队在讨论中反复提到"缺乏从0到1的工程经验"，你就知道你的论文阅读笔记不如一个能跑的demo有价值。
准备清单
入职前30天：建立"可提问"的基础
- 跑通团队当前最核心的Agent流程，不是读代码，是改一个参数看报错
找到团队repo中最近一个月被修改最多的Agent相关文件，把它在本地跑起来。然后故意改坏一个参数——比如把temperature调到2.0，或者把prompt中的某个关键词删掉——看错误日志从哪里开始，堆栈是怎么展开的。这个练习的目的不是"理解代码"，而是建立"我知道问题可能出在哪里"的直觉。很多新人花了两周"读代码"，但从未真正执行过任何一行。
- 整理一份"团队行话词典"，不是技术术语，是决策缩写
每个团队都有一些不为外人知的简称。我们团队把"这个需求先不做，等客户投诉了再说"叫做"PMF-driven deprecation"；把"LLM输出不稳定但先用规则兜底"叫做"deterministic fallback"。这些不是写在文档里的，是在Slack线程和会议中自然形成的。前30天你要做的，是收集10个这样的表达，理解它们背后的场景，而不是字面意思。
- 约一次和你直接对接的资深工程师的1:1，只问一个问题："如果我现在就要独立交付一个feature，我最缺什么上下文？"
不要问"你有什么建议给我"这种泛问题。具体的问题会得到具体的答案。我得到的回答往往是："你不知道我们的staging环境是怎么模拟LLM延迟的"或者"你不清楚我们和ML平台的权限边界"。这些是你自己看代码看不出来的。
- 找到团队最近一个"被放弃"的Agent项目，理解它为什么死
不是作为八卦，而是作为"这个团队的决策边界在哪里"的案例。是被技术可行性杀死的？还是业务优先级调整？还是关键人物离职？这个判断会告诉你"什么类型的风险在这个团队里是不可接受的"。
- （产品植入）系统性拆解面试结构——PM面试手册里有完整的Agent框架实战复盘可以参考
如果你还在面试阶段，或者想理解"团队怎么评估一个AI工程师的能力模型"，PM面试手册中关于Agent设计的系统性拆解值得一看。它不是理论框架，而是还原了真实面试中"候选人给出不同回答时，面试官的内心评分变化"——这种视角对你理解"前90天要证明什么"有直接帮助。
入职31-60天：从"看懂"到"能改"
- 主动认领一个涉及跨Agent通信的bug或feature
单Agent的逻辑相对直白，多Agent的协作才是团队真正的复杂性所在。找一个需要修改Agent间消息格式、状态同步或错误传播的任务。你会发现，真正的难点不在于"怎么写"，而在于"怎么定义'正确'的行为"——因为多个Agent的交互往往没有单一的正确答案，只有"在当前业务约束下可接受"的答案。
- 写一份"如果我来重写这个模块"的简短文档，不超过两页，然后给资深工程师看
目的不是真的推动重写，而是测试你的理解深度。如果他回答"这个我们考虑过，但问题是X"，你就学到了他脑中的约束条件；如果他回答"有意思，我们聊聊"，你就建立了一个技术影响力的切入点。前60天最忌讳的是"只执行不思考"，但也忌讳"只思考不暴露"。
- 记录一次你被LLM的不可预测性坑了的经历，写成团队的knowledge base条目
不是发在Slack里抱怨，而是结构化的记录：预期行为、实际行为、复现步骤、临时 workaround、长期修复思路。这个习惯会让你从"被坑的人"变成"帮团队减少被坑次数的人"。
入职61-90天：建立"局部权威"
- 主导一次关于Agent评估指标的技术讨论，提出"我们现在的指标可能漏掉了X"
前90天结束时，你应该能在某个细分领域提出"不是我知道更多，而是我发现了你们没注意到的东西"。Agent评估是最常见的切入点，因为大多数团队的评估体系都是半成品的：有准确率指标，但没有覆盖"有用但不对"的场景；有延迟指标，但没有区分"必要的推理时间"和"无效的循环"。
- 明确你接下来两个季度的"不可替代性"来源
不是"我会用LangGraph"这种可替代的技能，而是"我是唯一理解XX和YY交互边界的人"或者"我建立了团队第一个ZZ方面的自动化测试"。前90天的 culminating judgment 是：如果明天你要向团队证明"留下我"的价值，你的论据是什么？
常见错误
错误一：把"熟悉代码"等同于"理解系统"
BAD版本： "我第一周就把所有repo的代码都读了一遍，对整体架构有了初步了解。"
GOOD版本： "我花了两天时间，跟踪了一个用户请求从发起到Agent响应的完整路径，记录了三个'我不知道为什么会这样'的点，然后带着具体问题去问了资深工程师。其中一个点发现是三个月前的一个临时patch，大家都忘了还存在着。"
关键区别： 不是"我看了多少"，而是"我发现了多少团队可能也不知道的东西"。
错误二：追求"完美方案"，而不是"可迭代的判断"
BAD版本： "我在设计评审上提出了一个更优雅的Agent架构，但大家都很忙，没有采纳。"
GOOD版本： "我提出的重构方案在评审中被挑战'改动太大，会影响下周的发布'。我回去把它拆成了三个阶段：第一阶段只改接口不改实现，验证兼容性；第二阶段替换核心逻辑，保留回退能力；第三阶段清理旧代码。第二阶段被接受了，预计在下下个 sprint 实施。"
关键区别： 不是"我的想法对不对"，而是"我能不能把一个大判断拆成团队在当前节奏下能消化的步骤"。
错误三：把"学习"当成工作的替代品
BAD版本： "前两周我主要在熟悉业务和学习相关技术，还没有正式接手任务。"
GOOD版本： "入职第一天我就要求参加了一个正在进行的bug修复，虽然大部分时间我在旁边看，但我在第三个小时发现了一个日志格式的问题，提交了一个小的PR。这个经历让我理解了团队的代码提交规范，比读十遍CONTRIBUTING.md更快。"
关键区别： 学习必须 attach 到具体的、有后果的行动上，否则只是延迟面对真实判断的借口。
FAQ
Q1：如果团队的Agent框架我完全没用过，我应该先自学还是直接上手？
直接上手，但要有策略。 不是盲目地"边做边学"，而是在第一个任务中明确划分"我现在必须懂的"和"可以暂时当黑盒的"。例如，如果你要修复一个Agent工具调用的bug，你不需要先理解整个框架的并发模型，但需要理解"工具是如何被注册、描述、选择和调用的"这个具体链路。给自己设定一个时间盒：比如4小时内必须跑通复现，8小时内必须定位到代码位置。超过这个时间还搞不定，再去问——但问的时候要有具体的卡点，不是"这个框架怎么用"。
一个真实案例：新人工程师在入职第二天接到任务，我们的数据查询Agent偶尔会生成错误的SQL。他的第一反应是去刷LangChain文档的SQL相关章节，我阻止了他。让他做的第一件事是：找到过去一周所有相关的用户投诉，提取出"Agent生成的SQL"和"正确的SQL"的对比，自己先尝试找出模式。他在没有看任何框架代码的情况下，发现了70%的错误都集中在涉及日期范围的查询上——因为prompt中对日期格式的描述存在歧义。这个发现直接导向了修复方案，而他真正需要理解的框架代码，只是在最后提交时确认"我的修改应该放在哪个钩子函数里"。
判断原则： 框架是手段，不是目的。你的目标永远是"解决这个具体问题"，而"学会框架"是顺带的、可量化的副产品。
Q2：团队里似乎没有人懂Agent，我是应该 push 大家学，还是我自己先做出成果？
先做出成果，但成果的形式很重要。 不是"我先偷偷做，做好了再惊艳所有人"，而是"我用最小的可见进度，把'Agent可以这么做'变成团队的共同认知"。
具体做法：选择一个团队当前痛点最相关、但技术复杂度最低的Agent应用场景。比如，团队每天花大量时间手动整理客户反馈，你可以用半天时间搭建一个最简单的分类Agent，不是部署到生产，而是在下次团队会议上展示"这是过去一周反馈的自动分类结果，准确率大约X，这里有几个分类错误的我还没搞懂为什么"。这个展示的价值不在于方案本身，而在于它把抽象的"Agent能做什么"变成了具体的、可讨论的、有缺陷的真实物。
反直觉的点： 你不需要等到方案完善了再展示。实际上，有缺陷的早期版本更容易引发有价值的讨论——因为完美方案会让人无从插手，而有明确问题的方案会吸引别人来补充。"这个错误可能是因为prompt里少了个例子"——当同事这样插话时，Agent就从"你的项目"变成了"大家的事"。
Q3：面试官问"设计一个多Agent系统"，怎么回答才能拿到高分？
不是背诵架构，而是展示"在不同约束下的取舍判断"。
高分回答的结构：先明确约束（latency要求？准确性要求？可解释性要求？预算？），再给出在这些约束下的最小可行方案，最后主动暴露这个方案的弱点和你知道的替代方案。
具体示例："如果latency要求<2秒，我会选择单Agent+工具调用，而不是真正的多Agent协作，因为协调开销不可接受。但如果准确性要求优先，且可以接受5-10秒延迟，我会设计一个'评审Agent'来复核主Agent的输出，核心判断是：在这个场景下，延迟的用户体验损失小于错误回答的信任损失。这个评审Agent的关键设计是——它不能只是'再算一遍'，而必须基于不同的信息源（比如主Agent用实时搜索，评审Agent用缓存知识库），否则只是相关错误。"
面试官真正在听的是： 你有没有"没有免费午餐"的意识？你是否能区分"这个设计在当前约束下最好"和"这个设计 universally 最好"？你是否有具体的数字支撑你的判断（比如2秒 vs 5-10秒）？
结论
前90天的本质，是团队在用各种任务测试你"能不能在信息不完整的情况下做出合理判断"。Agent框架只是载体，真正的考察是你能否快速识别"什么是当前最重要的未知"，以及"在什么时间点必须从不确定性中抽身、做出承诺"。
你不是在学习一个技术栈。你是在通过技术栈，理解一群人如何在"不知道正确答案"的情况下持续前进——然后证明你能成为其中一员。
薪资参考（硅谷AI工程师，2024-2025）：
- Base： $100K - $250K（初级到资深）
- RSU： $50K - $400K/年（取决于公司阶段和级别）
- Bonus： $10K - $100K（含签约奖金和年终）
- 总包范围： $150K - $700K+（L3到L6+，未计入极端案例）
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。