直接写在 prompt

是自然语言约束（比如“如果要查天气就先调用天气接口”）。 模型“可能”照做，但不保证每次都严格执行。 适合规则说明、风格要求、流程引导。 缺点是可控性弱、难做参数校验、结果不稳定。

Function Calling

是结构化协议：模型要调用哪个函数、传什么参数，都是机器可校验的。 你可以强制只允许调用已注册工具，参数类型错误还能拦截。 适合真实动作（查数据、下单、发请求、写库）和多工具编排。 优点是稳定、可审计、易重试、易监控。

MCP（Model Context Protocol）可以理解成：把“工具接入”做成统一标准接口，让 Agent 不用为每个系统单独写一套适配。

优势 标准化接入：不同数据源/工具（GitHub、数据库、浏览器、内部系统）用同一协议接，降低集成成本。 可扩展性好：新增能力时只要加一个 MCP server/tool，不用大改 Agent 主逻辑。 上下文更清晰：资源（resources）、工具（tools）、提示（prompts）分层明确，便于治理。 权限边界更可控：可以按 server/tool 维度做授权和隔离，比“全能脚本”更安全。 跨模型/框架复用：协议层稳定后，换模型或客户端时迁移成本更低。 利于工程化：日志、审计、故障定位、限流、重试更容易统一做。

劣势 初始建设成本：要设计 server、schema、鉴权、部署，前期比“直接写 function calling”重。 性能开销：多一层协议与进程/网络通信，时延会比本地直调高。 调试链路更长：问题可能出在模型、MCP client、server、下游系统任一层。 Schema 维护负担：接口变化要同步更新描述，否则模型调用质量下降。 安全治理复杂度上升：虽然可控，但要真正安全需要完善权限、审计、密钥管理。 生态成熟度差异：不同 server 质量不一，稳定性和文档水平可能参差。 什么时候更适合用 MCP 你有多个工具/系统要长期接入； 需要团队协作和统一治理； 对可审计、可维护、可扩展要求高。 如果只是单一场景、小脚本、短期 PoC，直接 function calling 往往更快。

1. ReAct 和 Plan-and-Execute 有什么区别？各自的原理是？ 各适用于什么场景？ ReAct = 边想边做，反馈很强但慢且贵，适合路径不确定的探索性任务，比如搜索问答（循环执行 Thought → Action → Observation， 每步都让 LLM 决定下一步） Plan-and-Execute = 先想后做， 它更快更便宜，但灵活性弱，适合步骤较多、路径相对确定的流程化任务，比如报告生成。（先规划完整步骤，再逐个执行）

第一，业务理解。以后代码本身会越来越容易生成，但“为什么要这么做、这样做对业务到底有没有价值、约束在哪、优先级怎么排”不会自动生成。越往后，懂业务上下文的人越值钱。

第二，系统拆解和方案判断能力。不是会不会写某段代码，而是你能不能把复杂问题拆成清楚的模块，能不能判断哪些地方该抽象、哪些地方不该抽象，哪些技术债要还，哪些暂时不用还。这个能力是 senior 和单纯熟练工最核心的分水岭。

第三，AI 协作和验证能力。以后会用 AI 不是加分项，而是基础项。但真正值钱的不是“会不会让 AI 出结果”，而是“你能不能设定任务、约束输出、验证结果、把结果接入真实工作流”。说得再直一点，以后好的程序员不是不用AI，而是能比别人更稳定地把 AI 变成产出。

第四，文档表达和跨团队推进能力。很多 30+ 技术人后面想往上走，卡的不是技术，而是表达。能不能把方案讲清楚，能不能把 trade-off 写明白，能不能让别人理解你的判断，能不能推动协作落地，这些东西以后只会越来越重要。

AI coding 遇到的问题

按照SDD的方式进行了开发，大部分的时间都花在

1. 需求澄清 30% (与产品反复沟通需求细节，与AI 反复交流沟通实现方案)
2. 代码生成微调 10% （这部分很快，前期越请求， 生成的越准确， 有些小细节微调即可）
3. 代码理解验证上 70%（由于不理解历史代码逻辑， 没有办法快速判断AI生成的是否准确，如果想看懂每一行的代码， 比较花大量时间验证， 理解成本特别高） 自己的思考 LangChain LangChain 是一个用于开发由大语言模型（LLM）驱动应用的框架。其核心优势在于LangChain 表达式语言（LCEL），可以将各个组件“管道化”串联成链，实现清晰的线性流程：每一步的输出作为下一步的输入。适用于有向无环图（DAG）式的工作流，即流程单向且无循环。 典型应用场景： ・简单RAG：检索文档、生成提示词、获取LLM 答案 ・摘要生成：输入用户文本，调用摘要提示词，返回结果 ・信息抽取：从文本中提取结构化数据（如JSON） LangGraph LangGraph 是基于LangChain 构建的高级智能体系统库。它允许将工作流定义为图结构，节点为函数或LCEL 链，边为条件逻辑。最大优势是支持循环，可灵活实现任务重试、工具调用等，直到目标达成。LangGraph 显式管理应用状态，状态对象在节点间传 递并不断更新。 典型应用场景： ・多智能体系统：主管智能体分派任务给各专职智能体，可循环直到目标完成 ・计划‑ 执行智能体：智能体制定计划，执行步骤，根据结果循环更新计划 ・人类参与：流程可等待人工输入后决定下一步节点

LangChain LangChain 是一个用于开发由大语言模型（LLM）驱动应用的框架。其核心优势在于LangChain 表达式语言（LCEL），可以将各个组件“管道化”串联成链，实现清晰的线性流程：每一步的输出作为下一步的输入。适用于有向无环图（DAG）式的工作流，即流程单向且无循环。 典型应用场景： ・简单RAG：检索文档、生成提示词、获取LLM 答案 ・摘要生成：输入用户文本，调用摘要提示词，返回结果 ・信息抽取：从文本中提取结构化数据（如JSON）

LangGraph LangGraph 是基于LangChain 构建的高级智能体系统库。它允许将工作流定义为图结构，节点为函数或LCEL 链，边为条件逻辑。最大优势是支持循环，可灵活实现任务重试、工具调用等，直到目标达成。LangGraph 显式管理应用状态，状态对象在节点间传 递并不断更新。 典型应用场景： ・多智能体系统：主管智能体分派任务给各专职智能体，可循环直到目标完成 ・计划‑ 执行智能体：智能体制定计划，执行步骤，根据结果循环更新计划 ・人类参与：流程可等待人工输入后决定下一步节点

当应用流程清晰、可预测、线性时，选用LangChain（LCEL）；如果流程从A 到B 到C，无需回环，LangChain 是理想选择。

当需要智能体具备推理、规划、循环操作能力时，选用LangGraph。比如智能体需调用工具、反思结果、尝试不同方案，则需LangGraph 的循环与状态管理。

• 输入护栏（input guardrail）。

• 在请求进入 agent 之前过滤：

• • 长度限制：避免 prompt 注入超长上下文导致成本爆炸 / DoS
• • 注入模式：典型的 jailbreak/越狱关键词
• • 关键词黑名单：业务侧明令禁止的话题

• 输出护栏：脱敏 PII。

• 在把 agent 返回的文本/token 发给客户端之前，把可能泄露的隐私信息打码：

• • 中国大陆手机号 (1 开头 11 位)
• • 邮箱
• • 身份证号 (15 / 18 位，末位可为 X)
• • 中国大陆银行卡号 (16-19 位连续数字)

• 工具调用限流：每 sessionId 在固定窗口内最多 N 次。

• 简化实现：内存 Map + 10 分钟滚动窗口。生产应换 Redis。

• 为什么限流挂在工具层而不是请求层：

• • 一次用户请求里 agent 可能内部循环调多次工具
• • 防止 LLM 因为 tool 报错陷入死循环烧钱（曾经出过这种事故）

• 知识库检索工具（RAG 作为 tool）。

• 为什么 RAG 做成 tool 而不是预处理：

• • agent 自己判断要不要检索（"今天几号"不需要 RAG，"怎么退货"需要）
• • 可以连查多次（"我退货的运费谁出？" → 先查退货政策，可能还要查运费政策）
• • 与其他工具组合更自然

• 这就是 "agentic RAG"。

https://juejin.cn/post/7629927278534246427?searchId=20260611114434E85B115B0966D1463F96

https://juejin.cn/post/7596230910213259307