上一章把方向定下来了：一个 5~20 人研发团队的知识与效能助手，数据分三级。
这一章按标准流程往下走：定完方向之后是技术选型，再是最小骨架 MVP，不是直接写智能逻辑。
一、第一个冲动：上框架
方向一定，我第一反应是 pip install langchain。网上教程也这么带，十篇入门九篇开头先装框架，三行代码出来个能聊天的 agent，看着爽。
但我压住了。原因就一条：MVP 阶段框架是绑你的，不是帮你的。
- 你想自己控制循环，框架把循环封死了，得绕；
- 你想看一次调用的原始输入输出，框架包了三层，debug 得剥洋葱；
- 框架一升级，依赖跟着乱，版本地狱。
MVP 你需要的只是"把话问出去、把答案拿回来"的通道，用不到框架那些高级玩意（记忆、工具调度、多 agent）。所以取舍很清楚：MVP 阶段不用任何 agent 框架，原生代码裸写，等真正需要框架能力（循环/记忆/工具编排）时再引入。
二、选 Python，因为生态、因为更适合 AI
agent 核心用 Python 写。就两条理由：大模型工具链（LangChain、LlamaIndex、各种 SDK、论文示例）全是 Python 优先，生态现成；Python 天生更适合 AI 这摊事。没那么多纠结，将来和现有系统的集成坑是后话，MVP 先不管。
三、MVP 该有多"土"
有人 MVP 就上 RAG + 多 agent + 工作流，结果跑不起来，不知道哪层出问题。这是还没走就想跑。
MVP 我定义得刻意土：一个 system prompt + 一次对话补全，用户问一句答一句，不接知识库、不接工具、不加循环。目的不是功能多，是验证场景成不成立。答得还行，方向没偏；答得离谱，趁早调 prompt 或模型，成本极低。这时候堆 RAG/工具/记忆，一旦效果不好，你分不清是 prompt、模型还是检索的问题。
四、裸写的最小骨架
当时那个 MVP 的全部代码，最原生写法------一个 HTTP 请求，连 SDK 都没用（OpenAI 兼容格式，DeepSeek / 通义 / 智谱 都能用，改 base_url 和 model 即可）：
二十来行，当天就跑通了------请求发出去、答案回来、格式解析正常。注意这时候接的是裸云端模型，没有任何公司数据，答的就是通用知识，谈不上"答得对不对团队规范"。MVP 的目的本来就不是验证答案质量，是验证"用户问、模型答"这条通道通不通。通道通了，方向才算落地了第一步。
跑通后很快暴露一个限制：单次调用对付一问一答还行，任务稍复杂（"查上周缺陷数，跟前一周比，说趋势"）就废了------它得先查、再算、再总结，是好几步。这个限制先记着，后面碰到了再讲。
五、这章的坑，记一下
- 通用坑：MVP 别急着上框架。 原生跑通再谈框架，否则框架在你用不到它的时候绑你最狠。
- 企业级坑（提醒）：技术选型在企业里不是你一人定。 真实项目里选 Python、不上框架，得跟团队对齐------"后续谁维护""跟技术栈不一致怎么办"，个人项目不会有这层成本。
- 说明我自己的情况： 这个系列是我自己从零开始做、边做边分享，所以我凭经验直接选了"不用框架"------裸写能更好讲清原理、可控、好 debug，等后面真需要框架能力再引入。如果你是在公司里落地，这一步得换成跟团队对齐，不能像我这样自己拍板。
- 遗留问题：单次调用搞不定多步任务。 这是跑通后才暴露的下一个麻烦，留待后面解决。