AIHunter @TokenHunter168

说个暴论：FDE 长期来看，一定是个伪命题。 我也不认同所谓“垂直 Agent”和“构建业务数据飞轮”这套说法。 聊聊为什么。 1、FDE 现在能跑，靠的是比较优势。大部分企业还没用 AI，别人没用你用了，你就比对手强。FDE 帮你用上 AI，你就拿到了这份优势。 2、但 AI 越普及，这份优势就越薄。等大家都用上了，效率被拉平，企业真正的壁垒只剩一样：自己内部的业务流程和数据流程。 这恰恰是外部 FDE 最不懂的东西。FDE 能帮你用上 AI，但本质他们不懂你的业务。 3、所以数据飞轮在这里也不成立。对大多数企业来说，业务数据和工作流就是自身的核心竞争力。 你让 A 公司把自己的业务经验交给 FDE，等他积累完再去服务 B 公司吗？ 谁会把壁垒教给一个同时给竞对干活的人？ 4、再说点实际的。FDE 要落地，企业得先数字化，再 AI 化。可已经数字化的企业，自己就能很方便地把 AI 用起来，用不着 FDE。 还没数字化的呢？FDE 进去，干的基本就是数据清洗的脏活累活。 5、我不否认 FDE 能用 AI 帮企业降本增效、增收。 但更好的路，是企业自己培养懂 AI 的内部人才，而不是找外部的人来交付。 业务才是核心，是业务加 AI，不是 AI 加业务。

未来 5 年，AI 行业最值得关注的 8 个技术岗位，以及每个岗位应该学习什么。 我发现现在很多人学习 AI，最大的问题就是太喜欢追逐新东西了。 今天学 RAG，明天研究 Agent，后天又出来一个新的框架，天天都在学习，但始终不知道自己到底应该往哪个方向发展。 看完这份清单，我觉得有必要分享给所有想进入 AI 行业的人。 1. AI Engineer（AI 工程师） 把大模型真正集成到产品中，解决实际业务问题。 重点学习：RAG、Tool Calling、Evals、Python、API 开发。 2. Cybersecurity Engineer（网络安全工程师） 负责发现漏洞、防御攻击，保护系统和数据安全。 重点学习：红队/蓝队、网络安全、密码学、安全测试。 3. Agent Ops Engineer（Agent 运维工程师） 未来企业可能同时运行几十个甚至上百个 Agent，谁来保证它们能够稳定工作？ 重点学习：Tracing、任务队列、成本控制、监控和故障恢复。 4. AI Security Engineer（AI 安全工程师） 专门解决 AI 系统的提示词注入、敏感数据泄露、越权调用等问题。 重点学习：威胁建模、Red Teaming、Sandboxing、权限隔离。 5. AI Infrastructure Engineer（AI 基础设施工程师） 负责模型推理、GPU 资源调度和高性能 AI 基础设施。 重点学习：CUDA、Kubernetes、vLLM、GPU Scaling。 6. Cloud Security Engineer（云安全工程师） 保护部署在云端的 AI 服务、数据和基础设施。 重点学习：IAM、AWS/GCP 安全体系、云安全架构、合规。 7. AI Governance Engineer（AI 治理工程师） 确保 AI 系统的运行符合企业政策、法律法规和审计要求。 重点学习：Audit Logs、Policy as Code、EU AI Act、风险管理。 8. AI Evals Engineer（AI 评测工程师） 我认为这是未来非常值得关注的方向之一。 AI 能不能生成答案不重要，重要的是答案到底对不对，系统究竟可不可靠。 重点学习：测试数据集、LLM-as-Judge、Regression Testing、评测体系设计。 我自己这几个月一直在接触企业 AI 落地，越来越发现一个问题：现在做出一个 AI Demo 已经越来越容易了，但让它安全、稳定、低成本地运行，并且能够持续验证效果，依然非常困难。 一个 Agent 能够调用工具，不代表它能稳定执行任务；一个 RAG 系统能够回答问题，不代表它不会产生幻觉；一个 AI 产品能够上线，也不代表它能够长期可靠地运行。 所以我觉得，未来真正值得投入的，是那些能够解决真实工程问题的能力。 而且普通人完全没必要把这 8 个方向全部学一遍。先把 Python、SQL、HTTP、Git 这些基础打好，再根据自己的兴趣和职业目标选择一个方向深入。 对于想做 AI 应用落地、FDE 的人，我尤其建议关注 AI Engineering、Agent Ops、AI Evals 和 AI Security 之间的交集。 未来 5 年，岗位名称可能不断变化，框架可能不断被替代，但真正扎实的软件工程能力、系统设计能力、安全能力和验证能力，不会轻易过时。 不要只追着最新的 AI 工具跑，学会构建系统、验证系统、保护系统，让系统真正解决问题，这些能力可能比你掌握多少个热门框架重要得多。

Unnati @Unnati_builds24

3 days ago

8 roles that will matter most in the next 5 years & what to learn for each: 1.) AI Engineer - Ships LLM features into real products Learn: RAG, tool calling, evals 2.) Cybersecurity - Attacks and saves whole internet. Learn: Pick up one lane red team or blue team deep dive in

5 35 291 15K 329

Agent 一口气改了 Prompt、Skill，还动了执行代码，分数也涨了。可到底是哪一处改动起了作用？很多自进化实验其实答不上来。 最近看到一份 66 页的 Harness Self-Evolution 综述，挺值得收藏。 它系统梳理了 Prompt、Memory、Skill、Workflow 到可执行代码的自进化路线，还整理了 179 篇相关文献，附有中文版本。 我比较喜欢它对 Eval 的讨论。Harness 改了、分数涨了，还得看改动有没有真正生效、提升是不是它带来的，以及换个任务还能不能保持。 这三个问题我会直接拿来检查自己的实验：只要有一个答不上来，这次的「变强」就先别当真。 做 Agent 自进化、Harness 和 Eval 研究的建议先收藏，可以拿来当文献地图和梳理相关工作。 GitHub：github.com/zgcagi/Harness… 项目主页：zgcagi.github.io/Harness-RSI

评测分数涨了，Agent 实际却没变好。做 Eval 最怕的就是这种「假进步」，而且它往往不是 Prompt 的问题，是 Eval 本身的问题。 Anthropic 这篇工程博客讲的就是怎么避免它，还把整套流程做成了 Claude Code 的两个命令。 ① /claude-api build-eval 自动构建评估集，优先从真实任务和失败案例中选题，还会检查评分器是否稳定。同一份输出判两次，如果结果不一致，就得先检查 Eval。 ② /claude-api hillclimb 让 Claude 自动改进 Prompt、Skill 或 Harness，每轮提出一项修改，再用训练集和留出测试集验证。 如果训练集分数涨了，测试集却没提升，就撤回修改，避免 Agent 只记住几个失败案例。 而且当连续优化没有效果时，它还会反过来检查 Eval 本身有没有问题，比如题目含糊、评分规则写错。 实际案例中，他们在 44 个客服工单上做优化，最终把单次成本降到了约 1/5，留出集准确率从 78.6% 提升到 90.5%。不过样本量不大，还不能直接推广。 我觉得最值得抄的是两步：评分器判两次看是否一致，以及优化卡住时让 Agent 反过来质疑 Eval。评分器自己都不稳，后面分数的涨跌就没有意义。 但有一点要注意：每轮都用测试集决定是否保留修改，测试集其实也在参与调参。如果用它跑自动 hillclimb，我会额外留一份完全没碰过的数据，在那份数据上不涨，就说明是在给测试集调参，该回滚。 做 Agent Eval、或者正在手动调 Prompt 和 Skill 的，建议先收藏。 原文：claude.dev/blog/automatin…

非常推荐读一下 OpenAI FDE 负责人 Colin Jarvis 今天发的这篇工程博客！ 他们的 FDE 团队花了几个月给客户做 AI 系统，结果 Codex 变强后，直接删掉了约 90% 的定制代码。 文章用一个半导体客户的真实项目，讲清楚了 FDE 到底在做什么。 工程师直接深入客户团队，跟芯片专家一起设计 Eval、搭建 Harness，把 AI 真正用到芯片验证和调试流程里。 在这个行业，验证约占项目工作量的 70%。前 3–6 个月，几个场景都上了生产：定向测试生成节省约 48% 的时间，几周的调试被压缩到几小时。 但项目上线只是第一步。 随着 Codex 能力提升，团队把原来的定制应用逐步改造成通用 Harness 上的 Skills 和插件。Codex 本身成了交互界面，原来各场景单独写的终端界面和命令行工具全部退役。 扩展到新团队时，基本只需要换上新的连接器和 MCP，再用一个 Skill 生成新的 Eval。第一次部署花了两个月，复制到第二个团队只用了一天。 而当模型能力不够时，FDE 还要把真实业务中的失败案例和能力缺口反馈给 Research。一家电信客户做语音客服，模型一开始在关键 Eval 上只有约 60%，六个月里随着新模型迭代涨到 90% 以上，才达到上线标准。 我很喜欢作者提到的一个目标：让 FDE 不断减少别人对自己的依赖。 我觉得企业 Agent 项目里真正留得下来的，是 Eval、失败案例和沉淀成 Skill 的业务知识；为了补模型短板写的胶水代码，每次模型升级都该重新审一遍，随时准备删。 做企业 AI 落地的建议先收藏。如果你每接一个新客户都还在从头写一套，说明东西还停在定制应用这一层，没沉淀下来。 原文：openai.com/index/forward-…

块2027年了，真的没必要再纠结 ChatGPT、Claude、Gemini 到底谁最强了。 现在的 AI 已经越来越细分了，不同模型擅长的事情完全不一样。有的写代码强，有的做视频强，有的擅长语音，有的更适合处理复杂的多模态任务。 我重新整理了一份截至 2026 年 10 月，值得关注的 AI 工具与模型清单： 写代码：Claude Opus 5.5 + Claude Code 复杂推理：Gemini 4 Argon / GPT-6 Astra 生成图片：ChatGPT Images 2.5 精修图片：Ideogram 4.5 生成视频：Seedance 2.5 AI 配音：ElevenLabs Eleven v4 语音识别：Grok Voice Transcribe 2.0 图片识别与 OCR：Gemini 4 Argon 视频内容理解与提取：Gemini 4 Argon 生成音乐：Suno v6 生成 3D 模型：Tripo H3.1 / P2.0 视觉设计：Claude Design 个人 AI 助理：Grok Bot 以上是我目前比较推荐关注的一套分工，不代表它们在所有场景下都是绝对第一。 还有一个很多人容易弄混的地方：这里面有的是模型，有的是产品，还有的是 Agent。不是所有东西都需要调用 API，也不需要每个都单独买会员。像 ChatGPT Images 2.5，直接在 ChatGPT 里就能使用；Claude Code、Grok Bot 本身就是能够执行任务的 Agent。 我越来越觉得，AI 时代真正重要的已经不是你用了多少个模型，而是你能不能根据任务选对工具，再把它们组合成一套能够持续产出结果的工作流。 一个模型解决所有问题，未必是效率最高的方式。把合适的任务交给合适的 AI，可能才是更值得学习的能力。 这份清单肯定还会继续变化，模型迭代实在太快了。

最近听到一个很有意思的观点就是有些做过企业 AI 交付的人，反而不太愿意随便接纯 RAG 知识库项目。 我一开始觉得挺奇怪的。现在 RAG 不是非常成熟的一套技术方案了吗？Embedding、Chunk、向量数据库、混合检索、Rerank，这些东西网上教程一大堆，甚至你直接用一些开源框架，可能几个小时就能把一个知识库 Demo 跑起来，为什么真正交付的时候反而容易出问题？ 后来想了想，发现问题恰恰就出在这里——做出一个能回答问题的知识库和做出一个真正能够在企业内部长期使用的知识库，根本不是一回事。 首先，企业的数据通常没有你想象中那么干净。可能有几十份不同版本的制度文件，有些文档已经过期了，有些 PDF 根本解析不完整，有些表格的结构被打乱了，还有些知识本身就是互相冲突的。你把这些资料直接切块、向量化、丢给模型，最后生成出来的回答看着很流畅，但引用的可能是错误的文件，甚至是几年前就已经失效的规定。 更麻烦的还是测试和交付。客户随便拿出一个问题，你的系统没答对，就得回来调整检索策略、Chunk、Prompt 或者 Rerank。你修复了这个 bad case，下次可能又出现另外一个问题。假如前期没有一套完整的评测集，没有明确召回率、答案质量、引用准确性、拒答能力和权限隔离这些验收维度，项目就很容易变成无休止的优化。 RAG 真正值得学习的地方不是怎么把大模型接到向量数据库上，而是怎么处理真实世界里那些混乱、不完整、经常变化的数据。 一个成熟的企业知识库，应该能告诉用户这段答案来自哪里，知道哪些资料已经过期，在证据不足的时候能够拒绝回答，而且新的知识导入以后，之前的测试结果不能莫名其妙全部失效。 我不认为 RAG 没有商业价值，恰恰相反，我觉得能把这些问题真正解决的人，才有可能做出有竞争力的企业知识系统。毕竟客户花钱不是为了看你展示技术架构，而是为了获得一个真正敢用、能用、出了问题还能找到原因的系统。

woc，这绝对是我见过的最牛逼的coding工作流之一了，很长的一篇文章，但是全都是干货，值得花半小时好好看一看 相信能给大家(尤其是给需要自己afford token开销的程序员们）提供搭建工作流的思路，而且老哥很热衷于做实验搞清楚AI这个概率系统里到底是哪部分在生效、哪部分在出问题

张立行 @bylixing

3 weeks ago

如果 Agent 时代只能记住两个词，我会选 Context 和 Loop：一个决定 Agent 这一次做得好不好，一个决定它下一次能不能做得更好。Agent 调度应该是越来越轻松的，不要让自己成为系统的瓶颈。 x.com/i/article/2106…

18 89 526 89K 1K

快 2027 年了，我越来越觉得，单纯会开发 Agent，真的不算什么竞争力了。 现在 AI 圈有个特别割裂的现象。 一边是大家天天讨论最新的 Agent 框架、MCP、Skills、多智能体协作，恨不得让 AI 一个人干完一家公司的活。 另一边是你真正走进企业，发现很多项目连最基本的稳定性、权限管理、异常处理都没有解决。 卧槽，这种差距真的太明显了。 最近我自己也一直在折腾企业知识库、GEO 自动化、视频生产工作流，包括一些企业内部的软件系统。 做得越多，我反而越觉得：让 Agent 跑起来越来越容易了，让 Agent 真正跑进企业的业务流程里，才是最难的。 以前觉得接几个 API、调用几个工具、配置一套 Workflow，能把任务自动执行完，就算做出来一个挺不错的 AI 应用了。 但实际接触企业需求之后才发现，根本不是这么回事。 客户不关心你用了多少个 Agent，也不关心你调用的是 LangGraph、Dify 还是 Coze。 他只关心几个问题：原来三个人做的事情，现在能不能一个人完成？原来一天才能处理完的工作，现在能不能缩短到半小时？系统出错了怎么办？客户数据会不会泄露？后面谁来维护？ 你技术架构画得再牛逼，业务价值交付不出来，在客户眼里可能就是一个高级玩具。 而且我发现，Agent 开发正在越来越接近传统的软件工程。 尤其是 RAG，很多人以为做知识库就是上传几个 PDF，调用 Embedding，往向量数据库里一存，再接个大模型就完事了。 真正做起来才知道，麻烦的东西全在后面。 文档更新了怎么办？不同版本的内容发生冲突怎么办？员工能不能查到自己没有权限看的文件？检索出来的证据不准确怎么办？模型开始胡说八道怎么办？ 这些问题你不解决，模型再聪明也没用。 当然，不是所有 Agent 都需要 RAG，但只要涉及大量企业内部知识和数据，检索质量、权限控制和证据溯源就可能直接决定整个系统能不能用。 还有一点，我觉得现在特别多人忽略了。 AI 能帮你把代码写出来，不代表你就不需要懂软件工程了。 恰恰相反，以前你可能要花很多时间去写 Python、Java、SQL，现在 Codex 能帮你生成大量代码。 但系统怎么部署、接口怎么设计、任务失败怎么重试、数据怎么存储、并发怎么处理、日志怎么记录、线上怎么监控，这些工程责任不会因为 AI 会写代码就消失。 甚至因为代码生成速度太快了，系统质量的控制反而变得更加重要。 还有 Evals，我越来越觉得，做 AI 应用最忌讳的一件事，就是靠感觉验收。 今天改了几句 Prompt，问了五个问题，发现回答不错，就觉得自己优化成功了。 但真正到企业里，几百个员工、几千次调用、几十种业务场景，模型只要在关键任务上出现一次严重错误，就可能影响整个业务。 所以你必须知道任务成功率是多少、检索命中率怎么样、Tool 调用失败了多少次、每次任务花多少钱、哪些场景必须人工接管。 没有这些东西，所谓的优化，很多时候就是自己感动自己。 我现在甚至觉得，未来 AI 应用工程师之间最大的差距，可能不是谁会用更多的框架，而是谁能真正理解一个企业的业务，把需求拆解清楚，再用合适的技术把它稳定地实现出来。 这也是我为什么越来越关注 FDE 这个方向。 它不是让你坐在电脑前天天研究最新的模型，而是让你真正走进企业，弄清楚客户到底有什么问题，判断哪些值得用 AI 解决，再把系统交付出去。 当然，我自己也还在补这些工程能力，离真正成熟的企业级交付还有距离。 但至少方向越来越清晰了，AI 时代，会调用模型的人会越来越多，会开发 Agent 的人也会越来越多。 真正稀缺的，不是能够把 Demo 做得多么炫酷的人，而是能够对结果负责、对业务负责、对交付负责的人。 说到底，企业买的从来不是 Agent，企业买的是效率，是成本下降，是业务增长，是确定性。 谁能把这些东西真正交付出来，谁才有资格拿到下一阶段 AI 应用市场的钱。 会搭 Agent，只是入场券。能把 Agent 做成真正可用、可维护、可规模化的业务系统，才是竞争力。

同样是编程，一个让我爽到起飞，一个让我急到冒火 😂 DSH 里接上 DeepSeek V4.1 Flash 1017，简直就是一门一踩，库库就是干！Token烧起来根本不带眨眼的。 然后我把它接到 Claude 上…… 好家伙，真特么慢，但交付质量确实高。任务拆解、上下文管理、工具调用、验证闭环做得很好。难怪大家想尽各种办法也要用上A\的Agent。

2026 年想成为一名真正的 AI Engineer，这份面试清单确实值得收藏。 但我觉得，最值得关注的不是里面列出的 RAG、Agent、MCP、Evals、Fine-tuning 这 23 个技术知识点，而是文章最后那句话：Most interviews end with show me something you built. 以前总觉得，会调用几个大模型 API，会搭一个 Agent，会用几个框架，再加上 AI 编程工具，应该就算懂 AI 开发了。但真正接触企业项目之后才发现，能把 Demo 跑起来和能把产品交付出去，完全是两回事。 RAG 检索不到正确答案怎么办？Agent 调用工具出错怎么办？客户数据怎么隔离？API 超时怎么恢复？Token 成本怎么控制？系统上线以后出了 Bug，怎么定位、怎么修复，又怎么证明修复真的有效？ 这些问题，光靠会写 Prompt、会使用 Claude Code 或 Codex，是解决不了的。你可以让 AI 帮你写代码，但你至少得知道这段代码为什么这么写，出了问题该从哪里排查，最终能不能对交付结果负责。 所以我越来越觉得，未来 AI 工程师真正的竞争力，不是掌握了多少新工具、收藏了多少 GitHub 仓库，而是你有没有真正解决过问题，有没有完整做过一个项目，有没有从需求、开发、测试到部署交付的经验。 技术名词可以背，框架可以学，代码可以让 AI 辅助生成，但真正做过的项目、踩过的坑，以及解决问题的能力，是没办法靠背面试题替代的。 与其不断收藏新的 AI 学习路线，不如先把手里的一个项目真正做透。

Unnati @Unnati_builds24

5 days ago

Topics to prepare for AI engineering interviews in 2026: - How LLMs work: tokens, embeddings, attention, context windows - Prompting: system prompts, few-shot, structured outputs - RAG: chunking, embeddings, vector search, reranking - Hybrid search: keyword + semantic - Agents:

8 18 141 9K 183

看完这篇推文，我觉得现在 AI 工程师这个岗位，正在出现一个特别有意思的现象就是会用 AI 做项目的人越来越多，但真正具备 AI 工程能力的人，反而越来越难筛选。 现在打开 GitHub，随便找一个 RAG、Agent、智能客服的开源项目，借助 Codex、Claude Code，可能几个小时就能改出来一个自己的版本。再部署一下，录个演示视频，包装成项目经历，简历上就能写熟悉 RAG、Agent、向量数据库、MCP、多智能体协作。 但问题是，这些东西到底有多少是你真正理解的？ 我自己这几个月一直在接触企业 AI 落地，也一直在用 AI 辅助开发，越来越能感受到，AI 确实让做出一个东西变得非常容易，但它并没有让理解一个东西变得同样容易。 比如你做一个 RAG 知识库，能跑通 Demo 和能进入生产环境，完全是两码事。文档解析、混合检索、Rerank、权限隔离、增量同步、版本冲突、Evals、错误处理，哪一个环节出了问题，你能不能知道为什么？能不能定位？能不能独立设计测试去验证？ 很多人做项目只关心最后能不能跑起来，却很少关心为什么能跑起来、什么情况下会失败，以及失败以后怎么解决。 这其实是 AI 时代一个特别容易被忽略的问题：代码可以由 AI 生成，但工程判断不能完全外包给 AI。 我觉得这也是为什么越来越多企业会关注你怎么使用 Agent，而不仅仅是你做过什么项目。 因为现在项目本身已经越来越难证明一个人的技术水平了。真正能够拉开差距的是，你能不能提出正确的问题，能不能判断 AI 给出的方案是否合理，能不能设计 Evals，能不能在没有现成答案的时候自己解决问题。 当然，用 AI 开发没有任何问题。我自己也是 AI Coding 的重度使用者。关键不是代码是不是你亲手敲的，而是这个项目的技术决策、质量验证和最终结果，你到底能不能负责。 所以我越来越觉得未来 AI 工程师真正的竞争力，不是简历里堆了多少个框架，也不是 GitHub 上有多少个仓库，而是你对技术理解有多深，对业务判断有多准，对交付结果能承担多少责任。 AI 正在让开发能力变得越来越普及，但独立思考、工程判断和解决复杂问题的能力，反而会越来越值钱。 会用 Agent 的人很多，真正能驾驭 Agent、验证 Agent、为 Agent 的结果负责的人，才是未来企业真正需要的。

victor-wu.eth @victor_wu

5 days ago

来更新 AI 程序员面试心得 1. 看简历已经无法进行有效筛选了，全是 ai 润色过的，很难拉开差距 2. 90% 从业者干的是知识库和智能客服，心疼客服行业三秒钟 3. 基于 1 和 2，我们其实更看重一个人如何使用 agent 和对 agent 行业的追踪，我天天面试看到那些简历写 RAG RAG

96 52 659 89K 574

去年人人都在搭的知识库，为什么今年不火了？ 去年，“企业知识库”是 AI 落地阻力最小的一个项目，各家都在搭建自己的知识库，米哈游、银行、政企机构都在做。但到了今年，这个词突然没人喊了。 这是怎么回事？ RAG 凉了吗？ RAG 没死，但它被拆分并吸收进了现在模型的各个环节： 1. 长上下文的挤压： 上下文把很多中小型知识库整个吞掉了。去年 128k 上下文还是个奢侈品，但今年所有主流通用模型里，1M 上下文已经成了标配。几十万字的中型知识库，现在可以直接整本塞进上下文中，不用检索、不用调分、不用抗索引。 这样一来，RAG 的价值区间被压缩成了两类：一是大到装不下的知识库，二是需要极其精准命中的知识库。 2. Agent 架构的吸纳： 今年流行 Agent（Agent = Model + Harness）。在今年的 Agent 化趋势下，RAG 已经降级成了 Agent 的一个工具，或者说记忆检索插件。该不该搜，由 Agent 自己来决定。比如阿里的 Qoder，或者 DeepSeek 的 Harness，记忆检索与知识检索本来就是众多插件中的一个，在架构上被天然吸纳了。因此在独立叙事上，RAG 天然就熄火了。 今年还有一个新词：持续学习与 AI 的自我进化。 这就是所谓的新叙事，也是新的投资方向：知识到底应该存在哪里？以前我们的知识都是写在知识库里，而现在 know-how 类的知识，很可能会直接写进权重里。 这方面的代表就是 SSI 那一套 TTT（Test-Time Training）快速权重机制：每次使用时都会快速更新自我权重，不用检索，也不用塞上下文。这种自我进化的新叙事，比单纯的 RAG 吸引力大太多了。我自己也搭建过知识库，对此深有体会。

今年还在做Agent开发的人，应该都有感觉：岗位要求已经不是“会不会做”，而是“你做出来的东西到底能不能用”。 去年学个LangChain、接几个Tool、搭个聊天助手，就算挺新了。今年完全不是这个节奏。 通用Agent越来越难做出差异。去年大家喜欢做全能助手，什么都能聊一点。今年企业更愿意为具体问题买单：内部知识查询、客服处理、销售辅助、数据分析、研发提效。所以现在做Agent， 第一步不是想能接多少工具，而是先把业务流程拆清楚。你连业务边界都说不清，后面工具越多越乱。 RAG重新变得很关键。很多Agent项目最后都卡在同一个地方：模型能推理，但不知道公司内部的东西。这时候RAG就绕不过去。知识库、业务规则、历史文档、内部数据，检索质量不解决，Agent规划得再花哨，也是在错误信息上继续执行。所以RAG现在不是加分项，是基础能力。 框架会用，已经拉不开差距。LangGraph、Dify、Coze都能帮你快速搭流程。但真实项目更看：Tool失败怎么兜底？任务中断怎么恢复？上下文太长怎么处理？模型输出不稳定怎么校验？人工什么时候接管？这些问题框架不会自动帮你解决。值钱的是工程判断，不是API熟练度。 AI应用越来越像正常的软件系统。去年很多项目还停在Demo阶段，今年企业开始看部署、权限、日志、监控、成本和数据安全。FastAPI、Docker、Redis这些传统工程能力重新变得重要。有些项目还涉及私有化部署、本地模型和内部数据隔离。所以后端转AI，反而有天然优势。 评估开始成为必修课。去年不少项目改完Prompt，人工试几个问题，觉得“好像变好了”就敢上线。今年不行了。RAG要看检索效果，Agent要看任务完成率、Tool成功率，线上还得盯延迟、Token成本和Bad Case。没有评估，优化就是凭感觉。 MCP、多Agent可以学，但别追着热点跑。这些方向值得跟，但不是越早越好。一个Agent连RAG、Tool Calling、异常兜底都做不稳，过早上复杂架构只会把问题放大。 今年Agent开发真正的变化，其实就一句话：从“会搭”转向“会交付”。模型、RAG、Agent只是能力组件，能不能把它们接进真实业务，做成稳定、可维护、能算清效果和成本的应用，才是真正拉开差距的地方。

Anthropic 官方亲自下场做免费 Agent 课程，这份六脉神剑样的秘籍赶紧看： github.com/anthropics/cla… 它包括实战可用的6个案例，只要填上你的 API 就能用（小心你的IP地址） 1客服机器人 2金融数据分析助手 3电脑操作演示 4电脑操作最佳实践 5浏览器自动化演示 6自主编程 Agent A/ 总算做了件好事

确实，没毛病，大佬是干过大型项目的。 遇到重交付的B端项目，本质上还是外包的逻辑。 有流量、有品牌的公司，做标杆案例，做咨询、培训这种轻交付。 然后脏活儿累活儿，就外包给其他团队，挣点辛苦钱。 但是这些脏活累活，我总结下来大概跑不掉这3种： 1️⃣数据治理。本身数字化没完成，而AI极度依赖数据上下文，所以之前搞不定的数字化，现在你硬着头皮都得搞。 2️⃣传话筒：被当成皮球踢来踢去，老板说要你去敲打各个部门，部门那边让你回去找老板帮忙批预算或者反向洗脑。 3️⃣免费劳动力：哦呦，你不是大老板请来的专家吗？这个事情我搞不定，想必你这么专业，肯定不在话下。 …… 所以为什么但凡涉及驻场的项目和生意，几乎必亏钱。 因为投入非常巨大，最后你算了一下账，只能派实习生去驻场。 麦肯锡是这么做的，智谱之类的大厂也是这么做的。 接项目谈单子的，是头部品牌、顶级顾问，实际干活的，是刚毕业的大学生，最多再加上一个资深的B端项目经理，去管这帮大学生。 但是如果你不碰后面的交付，你就做一套解决方案，只是完成「咨询」和「培训」这两个事情，那么其实两全其美。 你说这种交付，有没有给客户提供价值，有没有解决他的问题呢？ 是解决了的。 因为你不给他做这套咨询方案，他就乱搞了，真的。 我见了好几个老板客户，买个百度数字人，在那边直播3个月，一个客户没有。 要么就是买炼刀RAP，想让AI操控微信和企业微信，自动当客服回消息，结果把一堆私域账号搞封号了。。 最近还有一个客户找上门来，说年初花了30万，请了一个顶级技术团队，帮他们定制了一套Agent。 结果半年过去，发现外面有个WorkBuddy，这个定制Agent根本就没有WorkBuddy好用。 这30万他留着不花，可以给公司用10年的API。。 你给他做一套「常识」方案，就已经是最好最扎实的交付了。 说来说去，最好的AI落地方案，就是搞数据治理，就是搭知识库、数据库，要么就是人家本来就有的数据系统，你给弄一堆接口，解决上下文的问题。 然后再一个部门一个部门，一个岗位一个岗位地搓Skill，解决具体工作问题。 最后再弄一套人才筛选培养激励机制，让公司出现一堆会Vibe Coding的人，然后就能自下而上涌现出一堆应用。 前期自上而下，老板给钱给资源。 后期自下而上，员工涌现一堆AI应用。 这个就是最好、最合适、最经济的AI落地方案。

我好像并没有提这个“重交付”吧。我再解释一下，其实我并不是说去交付什么，而且那些东西都是成品产品。我们给客户提供的是解决方案，我们做的是系统集成的事情。 关于在相应的平台上如何构建知识库，以及搭建智能体这一系列的事情： 1. 客户的自主构建：一般客户有信息化部门，确实会自己去做和构建。你看一些招标数据，基本上现在都会去采购一些私有化的智能体构建平台。 2. 实际落地的需求集中：但在实际落地时我们会发现，一个集团（尤其是一个大型集团）下面有很多二三级的生产类型单位，他们对智能体的诉求其实并不发生在集团本部，而是在下面的二三级生产单位。 在这种情况下，集团 IT 所收拢上来的智能体需求是非常庞大的。这已经不是传统的 IT 团队可以支撑的了。我们一般会建议用户做分类分级： 1. 核心、敏感的业务智能体：应该自己独立研发和创作。 2. 外围的智能体：可以进行对外交付，交给外部团队去做。但我认为这个外部团队并不是 FDM 团队，它只是一个软件二开或者叫外包团队。 这几件事我觉得应该拆开来看。我们今天只是想单独讨论一下：关于“咨询”以及“交付与培训”这两件事，具体的内容应该围绕什么开展？相应的框架该怎么设计？ 至于后面“交付”这件事，我是不做的，我不想做，我懒得做。具体做什么，我觉得是立功的活儿，我就不做了。我觉得有更需要通过这个去赚钱的人才要去做的。主要还是看要赚哪部分的钱。

卧槽，这是真做过 FDE 的人才能写出来的东西啊！！ 想做 FDE 的，直接看看大厂 AI 算法专家是怎么做的，照着学就完事了🫡 前天还看到一个卖 4999 的 FDE 训练营，结果课程里还在教coze…… 这篇直接降维打击，纯纯碾压，哥啊，你让别人怎么收费？🤣🤣

Miles Ma @miles_mazy

6 days ago

x.com/i/article/2112…

24 97 549 147K 1K

x.com/i/article/2112…

Claude Code 团队写了篇他们内部怎么做 code review 的，最好玩的一个细节是有个 PR 一晚上被 agent 审了又改、改了又审，跑了 50 多轮，最后是作者自己手动停掉的 他们回头 git blame 那些被反复标出来的问题，发现大约 59% 是 reviewer 第一轮就已经能看到的代码。它很少在找修改引入的新 bug，只是每轮再多挑出几个旧问题，所以怎么修都审不完 后来他们给 review 加了上限。审到第三轮就让作者退一步重新想方案，别再继续修，之后几轮只看 diff。人要不要审也不让作者自己选，由分类器按改动风险定，低风险不用人，中风险一个人，高风险两个人，agent 的 approve 也不算人。谁指挥 agent 写的 PR，谁就算一个必需的 reviewer 效果是一轮就过的比例从 65% 涨到 78%，要 5 轮以上的从 8.9% 降到 1.5%。现在 Claude Code 大约 90% 的代码是 Claude 自己写的 我一直觉得最好的用法是把写计划、实现和 review 拆开，交给不同模型搭着用。看完这篇感觉光拆开还不够，review 还得有停止条件，不然两个 agent 真能互相忙一整晚