--- title: "一份 AI 工程师的知识地图（2026 版）" date: 2026-05-02 slug: ai-engineer-map tags: ["AI", "LLM", "Prompt", "RAG", "MCP", "Agent", "Claude", "Cursor", "Ollama"] categories: ["AI"] description: "从大模型 / Prompt / RAG / MCP / Agent / 多模态 / 成本控制 / 编码工具一路捋下来,适合有技术背景的开发者快速建立 AI 知识框架。" draft: false --- > 适合有一定技术背景的开发者快速建立 AI 知识框架。涵盖核心概念、工程实践、工具选型,持续更新。 --- ## 一、基础层：大模型 一切的起点。Claude（Anthropic）、GPT（OpenAI）、Gemini（Google）、DeepSeek、Qwen（阿里）都是"引擎"，通过 API 对外提供服务，上层所有应用都建立在这些模型之上。 **主流模型对比：** | 模型 | 厂商 | 特点 | |------|------|------| | Claude 系列 | Anthropic | 长上下文强、指令遵循准确、代码能力突出 | | GPT-4o / o 系列 | OpenAI | 生态最成熟、多模态能力强、工具链完善 | | Gemini 系列 | Google | 原生多模态、超长上下文（1M token）、深度集成 Google 工具 | | DeepSeek | 深度求索 | 推理能力强、API 价格极低、开源友好 | | Qwen 系列 | 阿里 | 中文效果好、有本地部署版本、国内访问友好 | 模型能力差距在收窄，但复杂推理、超长上下文、低幻觉率这几个维度顶尖模型依然领先。选型时不能只看价格，要结合实际任务类型判断。 --- ## 二、理解模型的工作方式 在用 AI 之前，有两件事必须先搞清楚，否则会踩很多莫名其妙的坑。 ### 上下文窗口（Context Window） 模型每次能"看到"的文本总量是有上限的，这个上限叫上下文窗口，输入和输出加在一起不能超过这个数。 **各模型上下文窗口：** | 模型 | 上下文窗口 | | ----------------- | ---------- | | GPT-4o | 128K token | | Claude Sonnet 4.6 | 200K token | | Gemini 1.5 Pro | 1M token | | DeepSeek-V3 | 128K token | 1 token 大约是 0.75 个英文单词，中文每个字大约 1～2 token。200K token 大概是一本 30 万字的书。 **两个重要的坑：** 第一，超出窗口后，模型不会报错，而是"忘掉"最早的内容。如果你把一段很长的代码库塞给 AI，它可能已经把最开始的文件内容忘了，给出的建议会出现前后矛盾。 第二，"Lost in the Middle"问题——研究发现，模型对窗口开头和结尾的内容记忆最好，中间部分最容易被忽略。所以关键信息要放在 prompt 的开头或结尾，而不是埋在中间。 ### AI 幻觉 模型生成文字的本质是**预测下一个概率最高的 token**，不是在查找事实。这意味着它在不确定的时候不会说"我不知道"，而是倾向于生成一段"听起来合理"的内容。 **减少幻觉的主要手段：** - **RAG**：把真实文档片段塞进 prompt，给模型"答题材料"（详见第四节） - **降低 temperature**：temperature 越低，输出越保守、越确定；越高，越有创意但越容易编造 - **Chain of Thought**：让模型先一步步推理，再给结论，减少跳步错误 - **引用溯源**：要求模型回答时标注来源段落，可验证 - **RLHF 训练**：厂商通过人类反馈训练模型，让它学会说"我不确定" 幻觉目前无法彻底消除。法律、医疗、财务等高风险场景无论模型多强，都必须有人工审核兜底。 --- ## 三、Prompt Engineering Prompt 是和 AI 沟通的唯一渠道。写得好和写得差，效果差距可以很大。几个立竿见影的技巧： ### 系统提示词（System Prompt） 在对话开始前，用系统提示词定义 AI 的角色、能力边界和输出要求。这是最基础也最重要的一步。 ``` 你是一个游戏后端开发专家，熟悉 .NET 和 SQL Server。 回答时： - 使用 C# 代码示例 - 指出潜在的性能问题 - 如果不确定，直接说不确定，不要猜测 ``` ### Few-shot 示例 与其描述你想要什么，不如直接给 2～3 个输入-输出的例子，模型会自动理解规律。 ``` 将以下日志条目格式化为 JSON： 输入：[2026-03-18 14:23:01] ERROR UserService 用户登录失败 uid=10234 输出：{"time":"2026-03-18 14:23:01","level":"ERROR","service":"UserService","msg":"用户登录失败","uid":10234} 输入：[2026-03-18 14:25:43] INFO PayService 支付成功 orderId=88765 输出： ``` ### Chain of Thought（思维链） 在 prompt 里加上"请一步一步思考"，让模型把推理过程写出来再给结论。对复杂问题效果显著，错误率明显下降。 ``` 请一步一步分析这段 SQL 的性能问题，然后给出优化建议。 ``` ### 指定输出格式 明确告诉模型输出的结构，否则格式会很随意，后续解析麻烦。 ``` 请用以下 JSON 格式返回结果，不要有其他内容： { "issue": "问题描述", "severity": "high|medium|low", "suggestion": "修复建议" } ``` ### 反面示例（告诉模型不要做什么） 光说"要做什么"有时候不够，同时说"不要做什么"往往更有效。 ``` 分析这段代码，不要重复我已知的内容，不要给出明显的建议， 直接定位最可能导致线上 bug 的地方。 ``` ### 常见误区 - **Prompt 越长越好**：不对，冗余信息会稀释关键指令，模型容易抓不住重点 - **"请帮我"、"谢谢"有用**：没有，礼貌词不影响输出质量 - **一次写好 prompt**：Prompt 是需要反复调试的，像调代码一样迭代 --- ## 四、核心技术 ### RAG（检索增强生成） **解决的问题：** AI 不知道你的内部数据，也不了解你业务的最新状态。 解法不是训练模型（成本高、周期长、数据泄露风险大），而是在每次查询时，把相关文档片段检索出来，临时塞进 prompt 一起发给 AI。 **完整流程：** ``` 【离线】文档切片 → Embedding 向量化 → 存入向量数据库 【在线】用户提问 → 问题向量化 → 检索相关片段 → 拼 prompt → AI 生成回答 ``` **检索方式要按场景选：** | 场景 | 推荐方式 | |------|---------| | 语义模糊查询 | 向量检索 | | 精确关键词匹配 | 全文检索（ES / BM25）| | 结构化数据 | 直接 SQL | | 实时状态数据 | 直接调接口 | 生产环境通常用**混合检索**（向量 + 关键词并行），再加 **Reranker** 对两路结果重排融合，效果比单一检索稳定得多。 **RAG 效果差的常见原因：** - 切片粒度不合适：太大检索不精准，太小上下文断裂 - Embedding 模型语言不匹配：中文内容要用中文模型 - 缺 Reranker：向量相似度不等于语义相关，需要二次排序 --- ### Function Calling / Structured Output **解决的问题：** 默认情况下模型输出自由文本，开发者要从中解析结构化数据很麻烦，而且不稳定。 Function Calling 让模型直接输出结构化的函数调用参数，或者严格按 JSON Schema 输出。这是开发者在系统里接入 AI 时几乎必用的能力。 **三种形式：** **JSON Mode**：告诉模型必须输出合法 JSON，但不约束具体字段。 **Function Calling**：你预先定义一组函数和它们的参数 Schema，模型自己判断什么时候调哪个函数，以什么参数调用。 ```csharp // 定义函数供模型选择调用 var tools = new[] { new Tool("get_player_info", "查询玩家信息", new { type = "object", properties = new { playerId = new { type = "string", description = "玩家ID" } } }) }; // 模型判断需要查询玩家时，会返回： // { "name": "get_player_info", "arguments": { "playerId": "10234" } } // 你的代码执行后，把结果再传回给模型 ``` **Structured Outputs**：最严格的形式，模型输出必须完全符合你指定的 JSON Schema，字段和类型都有保证，不会多也不会少。 **适合使用的场景：** - 从非结构化文本中提取信息（日志分析、邮件解析） - 让 AI 决策后直接触发业务逻辑 - 任何需要程序化处理 AI 输出的场景 --- ### 多步骤编排 AI 作为整个流程的指挥者，自主判断下一步做什么、调哪个工具，直到任务完成。 ``` 用户："分析上个月的流失情况并发报告给运营" ↓ AI → 调 GetChurnData(month=3) ↓ AI → 调 GetChurnByServer() ↓ AI 整合数据，生成分析报告 ↓ AI → 调 SendEmail(to="运营组") ``` Semantic Kernel 的 Plugin 机制就是干这件事的。 --- ### Fine-tuning（微调）vs RAG 两者经常被混淆，但解决的是不同问题： | 维度 | RAG | Fine-tuning | |------|-----|-------------| | 解决的问题 | 模型不知道你的数据 | 模型不擅长你的任务风格 | | 数据要求 | 文档即可 | 需要大量高质量的输入-输出对 | | 更新成本 | 低，随时更新文档 | 高，每次更新需要重新训练 | | 适合场景 | 知识库问答、文档检索 | 特定领域语气/格式/专业术语 | | 费用 | 低 | 高 | **结论：** 绝大多数企业场景先上 RAG，Fine-tuning 只在 RAG 效果不够好、且有大量标注数据的情况下考虑。 --- ## 五、接入方式 ### 直接调 API 本质就是一个 HTTPS POST，传 prompt，拿结果。简单、可控、成本透明。 适合的场景：活动文案生成、内容翻译、用户评论分析、客服自动回复、日志摘要生成等固定业务场景。 如果公司只用一个模型、场景固定，直接封装一个 `AiService` 类就够了，不需要引入额外框架。 --- ### Semantic Kernel（编排框架） 微软出品，支持 .NET / Python / Java，对 .NET 技术栈的团队非常友好。 类比为 AI 领域的 EF Core——屏蔽不同模型间的 API 差异，业务代码面向接口编程，换模型只改配置。 ```csharp // Program.cs builder.Services.AddKernel() .AddAnthropicChatCompletion("claude-sonnet-4-6", apiKey); // Service 层注入使用 var result = await kernel.InvokePromptAsync("分析这个玩家的充值行为：{{$input}}"); ``` 适合场景：多步骤 AI 编排、RAG、需要支持多模型切换的团队项目。 --- ### MCP（Model Context Protocol） Anthropic 于 2024 年 11 月发布的开放协议，定义了"AI 如何标准化调用外部工具"，现已成为全行业事实标准。 - 2025 年 3 月 OpenAI 全面跟进 - 2025 年 12 月捐给 Linux 基金会，OpenAI、Google、微软均为成员 - 目前 10,000+ MCP Server，月下载量 9700 万 ``` AI 客户端（Claude / Cursor / Antigravity） ↓ MCP 协议 MCP Server ← 你来实现这一层 ↓ 你的业务系统 / 数据库 / 内部接口 ``` MCP Server 是独立进程，和现有系统完全解耦，任何语言都能写。写好之后，所有支持 MCP 的 AI 客户端都能调用你的系统。 **和直接调 API 的本质区别：** 直接 API 是"你的代码决定每一步，AI 只是执行节点"；MCP 是"AI 自己决定走几步、调哪个工具"——控制权从代码转移到了模型。 --- ### 本地部署（Ollama） **解决的问题：** 数据不能出公司网络，或者不想持续付 API 费用。 Ollama 是一个工具，把主流开源模型打包成可以在本地直接运行的形式，接口和 OpenAI API 完全兼容，切换成本接近零。 ```bash # 安装后一行命令拉模型并启动 ollama run qwen2.5:14b # 用标准 OpenAI 格式调用本地模型 curl http://localhost:11434/v1/chat/completions \ -d '{"model":"qwen2.5:14b","messages":[{"role":"user","content":"你好"}]}' ``` **可运行的主流模型：** | 模型 | 参数量 | 最低显存 | 特点 | |------|--------|---------|------| | Qwen2.5 | 7B / 14B | 8GB / 16GB | 中文效果好，阿里出品 | | DeepSeek-R1 | 7B / 14B | 8GB / 16GB | 推理能力强，开源 | | Llama 3.3 | 70B | 48GB+ | Meta 出品，综合能力强 | | Mistral | 7B | 8GB | 速度快，适合简单任务 | **适合的场景：** - 处理公司内部敏感数据（数据库连接串、用户信息） - 代码补全类任务（质量接近商业模型） - 高频调用、成本敏感的场景（本地跑不计 token 费用） **不适合的场景：** 复杂推理、多语言翻译、需要最新知识——这些目前本地模型和顶尖商业模型还有明显差距。 --- ## 六、多模态 多模态指模型能同时处理多种类型的数据。目前最成熟的是**文本 + 图像**，主流模型（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro）都已全面支持。 **实际能做什么：** - **截图转文字**：把 UI 截图发给 AI，让它描述问题或生成对应代码 - **图表分析**：把折线图、柱状图截图发给 AI，它能读懂数据并给出分析 - **文档图片解析**：扫描件、截图中的表格、合同内容提取，不需要 OCR 前处理 - **设计稿转代码**：把 UI 设计图发给 AI，让它生成 HTML/CSS 框架（不是完美的，但能省很多时间） **在代码里调用视觉能力：** ```python import anthropic, base64 with open("screenshot.png", "rb") as f: img_data = base64.standard_b64encode(f.read()).decode("utf-8") client = anthropic.Anthropic() message = client.messages.create( model="claude-sonnet-4-6", messages=[{ "role": "user", "content": [ {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": img_data}}, {"type": "text", "text": "这个页面的布局有什么问题？"} ] }] ) ``` **当前局限：** 视频理解在部分模型上支持，但效果不稳定；实时音频目前只有 GPT-4o 的 Realtime API 支持，成本较高。 --- ## 七、成本控制 用 API 很容易不知不觉花很多钱，几个实用的省钱方法： ### 模型路由（按任务难度选模型） 不是所有任务都需要最贵的模型。建立一个简单的路由规则，根据任务复杂度选不同模型： | 任务类型 | 推荐模型 | 大约成本比 | |---------|---------|-----------| | 简单分类、关键词提取 | Claude Haiku / GPT-4o-mini | 1x | | 普通问答、代码补全 | Claude Sonnet / GPT-4o | 10x | | 复杂推理、长文档分析 | Claude Opus / o3 | 50x+ | ### Prompt 缓存（Cache） 如果你每次请求都带着相同的系统提示词或大段文档，Anthropic 和 OpenAI 都支持 Prompt Cache——相同内容只计算一次，后续请求的这部分最多打 9 折，最高可省 90% 的输入 token 费用。 ```python # Anthropic Cache Control 示例 messages = [{ "role": "user", "content": [ { "type": "text", "text": very_long_system_doc, # 长文档 "cache_control": {"type": "ephemeral"} # 标记为可缓存 }, {"type": "text", "text": user_question} # 每次变化的问题 ] }] ``` ### Batch API 对于不需要实时响应的任务（比如批量分析日志、批量生成文案），使用 Batch API 可以享受约 50% 的价格折扣，代价是处理时间延迟到几小时内完成。 ### 控制 Output 长度 输出 token 的价格通常是输入的 3～5 倍。明确告诉模型输出长度： ``` 请用不超过 3 句话回答，不要有多余解释。 ``` ### Token 计算工具 OpenAI 和 Anthropic 都提供 Tokenizer 工具，可以在发送前估算费用，避免意外超支。 --- ## 八、工具生态 ### LlamaIndex 专注 RAG 场景的 Python 框架，文档处理、向量检索、多路检索融合都做得很深。上手快，适合快速搭 RAG 原型。 ```python # 建索引（离线，跑一次） documents = SimpleDirectoryReader("./docs").load_data() index = VectorStoreIndex.from_documents(documents) # 查询（在线，每次请求） query_engine = index.as_query_engine() response = query_engine.query("这个接口的限流规则是什么？") ``` **向量库选型：** | 选项 | 适合情况 | |------|---------| | PostgreSQL + pgvector | 已有 PG，成本最低，省事 | | Qdrant | 自部署，高性能，适合大规模 | | Pinecone | 不想运维，直接用云托管 | --- ### OpenClaw 2025 年底爆火的开源 AI Agent，60 天内积累 24.7 万 GitHub Star。核心理念是：**以消息平台作为操作界面，让 AI 替你在本机或服务器上自主执行任务**。 你不需要打开任何 App，直接在 Telegram、Slack、微信里发一条消息，AI 就能完成文件操作、调接口、发邮件、查数据——完全跑在你自己的机器上，数据不出去。 **支持 50+ 消息平台：** WhatsApp、Telegram、Slack、Discord、微信（WeCom）、钉钉、飞书、Teams、Signal、iMessage…… **两种能力扩展机制：** - **Skills（技能包）**：结构化的"操作手册"，明确告诉 AI 在特定场景下按什么顺序调哪些工具。社区已有 100+ 预置 Skills，可以自己写，甚至让 AI 来写新的 Skill - **MCP**：对外连接标准协议，把公司内部系统接进来。Skills 解决"什么时候怎么调"，MCP 解决"能不能调" **典型使用场景：** - 在 Telegram 里发"帮我拉今天的错误日志，整理成表格" - 定时任务：每天早上自动查数据库、生成日报、发给指定群 - 接入公司内部系统，变成团队共用的 AI 助手机器人 **部署：** 支持 Windows / macOS / Linux 本地部署，也支持阿里云、腾讯云一键部署，国内中文社区资料丰富。底层默认接 Claude，也支持 GPT、DeepSeek、Qwen。 2026 年 2 月原作者加入 OpenAI，项目移交开源基金会，仍在活跃维护。 **MiMo Claw（小米）** 是同类产品，深度接入小米生态，一键部署，适合已在用小米设备的用户。 --- ## 九、企业级 AI 应用场景 | 场景 | 推荐方案 | 备注 | |------|---------|------| | 智能客服 | 直接调 API + RAG | AI 先回答，答不了查知识库，再不行转人工 | | 活动文案生成 | 直接调 API | 给模板和关键词，批量生成 | | 内部知识库问答 | RAG | 开发文档、运营手册、配置说明 | | 代码 Review | 直接调 API | 提交 PR 时触发，自动给出评审意见 | | 日志分析 / 排障 | 直接调 API + Structured Output | 从非结构化日志提取关键信息 | | 数据分析 | 直接调 API + SQL | 自然语言转 SQL，结果解释成人话 | | 合同 / 文档审查 | RAG | 检索相关条款 + AI 比对分析 | | 跨系统自动化任务 | 多步骤编排 + MCP | 自动拉数据、生成报告、发通知 | | 图片内容审核 | 多模态 API | 截图、UGC 图片内容检测 | | 游戏内容生成 | 直接调 API | NPC 对话、任务描述、世界观文本 | --- ## 十、AI 编码工具 > 模型能力溢出之后，竞争从"谁的模型更聪明"转移到"怎么把模型能力接进工作流"。AI 编码工具是开发者目前最直接感受到生产力变化的地方。 ### ⚠️ 使用前必看：翻墙说明 **Claude 系（claude.ai、Claude Code）：必须虚拟网卡模式** 普通代理（SSR、V2Ray 仅配系统代理）大多数情况下无法使用，Claude 会检测 IP 质量。必须使用 **TUN 模式**（虚拟网卡），让所有流量走网卡层，比如 Clash Verge 开启 TUN 模式，或者使用 Warp。 **其余工具：普通代理即可** Cursor、GitHub Copilot、Antigravity、Codex 对代理要求没那么严，配置好系统代理即可。 --- ### IDE 派 #### GitHub Copilot 最老牌的 AI 编码助手，GitHub 出品，深度集成进 VS Code、JetBrains 全家桶、Visual Studio，不需要换编辑器。 - **行内补全**：预测下一行或下一段，Tab 接受 - **Copilot Chat**：侧边栏对话，解释代码、找 Bug、生成测试 - **Copilot Edits**：跨多文件批量修改 - **Copilot Agent**：自主完成较复杂任务，可以发 PR 底层以 GPT 系列为主，近期加入 Claude 和 Gemini 可选。 **价格：** 免费版（2000 次补全 + 50 次 Chat）/ Pro $10/月 / Pro+ $39/月 / 学生免费 **翻墙：** 普通代理即可 --- #### Cursor 最早把 AI 深度集成进编辑器的产品，2024 年爆火，目前是这个赛道标杆。基于 VS Code fork，迁移成本接近零。 - **Tab 补全**：预测整段要改的内容，改了函数签名，调用处参数一并改好 - **Cmd+K**：选中代码 + 描述，直接内联修改 - **Chat 侧边栏**：带完整代码库索引，跨文件理解逻辑 底层模型可选：Claude、GPT-4o、DeepSeek 都支持。 **价格：** 免费版 / Pro $20/月 / Pro+ $60/月（积分制，月积分 = 套餐价美元数） **翻墙：** 普通代理即可 --- #### Google Antigravity Google 2025 年 11 月随 Gemini 3 发布，VS Code fork，理念比 Cursor 更激进。 - **Editor 模式**：类似 Cursor，Tab 补全 + 内联改 + 侧边 Agent - **Manager 模式**：同时派发多个 Agent 并行处理不同任务，统一监控 AI 拥有直接操作文件系统、终端、内置浏览器的权限，同时支持 Claude 和 GPT。 **价格：** 免费版（重度使用 2-3 小时触达限额，7 天刷新）/ Pro $20/月 / Ultra $250/月 **翻墙：** 普通代理即可 --- ### CLI Agent 派 > 你说清楚要做什么，AI 自己去读代码、改文件、跑命令，完事汇报。 #### Claude Code Anthropic 出品，目前公认 Agent 能力最强的 CLI 工具。 ```bash claude "找出所有数据库查询超过 500ms 的接口，加上耗时日志并写单元测试" ``` - 完整的文件读写和终端执行权限 - 擅长跨文件理解和大范围改动 - 支持 MCP，可接入自定义工具 - SSH 进服务器也能用 **价格：** Claude Pro $20/月 起（无免费版），重度用 Max $100/$200/月；也可 API Key 按 token 计费 **翻墙：** ⚠️ 必须 TUN 模式虚拟网卡 --- #### Codex（OpenAI） OpenAI 2025 年 4 月发布，沙箱隔离运行，多任务并行，token 效率约为 Claude Code 的 4 倍。 **价格：** 工具开源免费，走 ChatGPT Plus（$20/月）或 OpenAI API 额度 **翻墙：** 普通代理即可 --- ### 综合对比 | 工具 | 类型 | 价格 | 翻墙要求 | 亮点 | |------|------|------|---------|------| | GitHub Copilot | IDE 插件 | 免费 / $10 / $39 | 普通代理 | 不换编辑器，企业管控友好 | | Cursor | IDE（VS Code fork）| 免费 / $20 / $60 | 普通代理 | Tab 补全体验最好，主流首选 | | Antigravity | IDE（VS Code fork）| 免费 / $20 | 普通代理 | 多 Agent 并行，最激进 | | Claude Code | CLI Agent | $20~$200/月 | ⚠️ 必须虚拟网卡 | Agent 能力最强，支持 MCP | | Codex | CLI Agent | API 按量 / $20+ | 普通代理 | token 效率高，沙箱隔离 | 两个流派不互斥：日常用 Cursor，复杂重构或批量任务丢给 Claude Code。 --- ## 十一、关键判断：什么时候用什么 **直接调 API 就够了，当：** 业务场景固定、输入输出明确、公司只用一个模型、团队规模小不需要统一抽象。 **需要引入 Semantic Kernel，当：** 需要多步骤编排、做 RAG、在多模型间切换、有多个团队共用 AI 能力。 **需要 MCP，当：** 想让 AI 主动操作你的系统、想让 Cursor / Claude Desktop 直接访问内部数据、在构建 Agent 类产品。 **需要 RAG，当：** AI 需要访问内部文档或私有知识库、不想训练模型、回答结果需要能溯源到具体文档。 **用本地部署（Ollama），当：** 数据不能出公司网络、高频调用成本敏感、对推理质量要求不是极高。 **用多模态，当：** 需要处理图片内容、截图分析、UI 稿转代码、图表数据提取。 --- ## 十二、现状与趋势 **已经发生的：** - MCP 在 16 个月内成为 AI 工具调用的事实标准，速度远超以往任何协议 - AI 编码工具从"补全代码"进化到"自主完成任务"，Cursor 的 Tab 到 Claude Code 的 Agent 只用了不到两年 - 多模态从实验功能变成了主流模型的标配能力 - 模型各家差距在收窄，工具层和工程实践的差异越来越重要 **正在发生的：** - 多 Agent 并行协作（一个任务拆给多个 AI 同时跑）从实验室走向产品 - "Vibe Coding"——用自然语言描述，让 AI 生成整个功能模块——正在成为部分开发者的主力工作方式 - 本地部署模型质量快速追赶商业 API，轻量任务本地跑已经够用 - 各大云厂商开始把 AI Agent 能力直接内置进开发平台 **还没解决的：** - 真正落地的企业级 AI 产品依然不多，大部分还在 POC 阶段 - 生产环境的效果稳定性、成本控制、幻觉处理依然是难点 - AI 有了文件和终端权限之后，安全和误操作风险如何防控 - 长上下文场景下的效果一致性：窗口大了不代表记忆力变好