AI 工程不只是调用模型，还包括上下文、工具、工作流和安全边界。
AI Agent
AI Agent 可以理解为连接用户目标和大语言模型能力的执行层。
它通常包含：
- 理解任务
- 规划步骤
- 调用工具
- 读取结果
- 调整策略
- 输出最终答案
例如编码 Agent 可以搜索代码、修改文件、运行测试、解释错误。
MCP
MCP 可以理解为模型连接外部工具和数据源的一种协议方式。
它让模型能以结构化方式访问：
- 文件系统
- 数据库
- GitHub
- 设计工具
- 企业知识库
关键价值是把工具能力标准化，而不是每个应用单独适配。
Prompt
Prompt 是给模型的任务说明和上下文。好的 prompt 通常包含：
- 明确目标
- 输入数据
- 输出格式
- 约束条件
- 示例
Prompt 不是魔法，本质上是把任务边界说清楚。
Function Calling
Function Calling 让模型输出结构化参数，由程序调用真实函数。
典型流程：
- 用户提出需求
- 模型判断需要调用哪个函数
- 模型生成参数
- 程序执行函数
- 模型根据结果继续回答
这能让 AI 系统更可控，也方便接入业务系统。
延伸理解
复习这篇时，不要只记住名词，要把重点放在 Agent 边界、工具调用、MCP 上下文协议、提示词结构和 Function Calling 的工程落地。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- 先明确系统里哪一部分由模型判断，哪一部分必须由代码、权限和数据约束保证。
- 不要把提示词当成唯一安全边界；涉及外部动作时，应有 schema、审计日志、重试和人工兜底。
- 评估 Agent 时要看任务完成率、错误恢复能力、工具选择是否稳定，而不是只看单轮回答是否流畅。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个“自动整理资料并调用工具”的 Agent 项目里理解：用户输入目标，模型负责拆解任务，工具层负责搜索、读取文件、调用 API 或写入结果。真正的难点不在于让模型说出计划，而在于控制它能访问什么、能执行什么、失败时如何回滚、输出是否能被验证。MCP 适合用来把外部上下文标准化暴露给模型，Function Calling 适合把模型意图转换成受约束的函数参数。实现时要把权限、参数 schema、超时、重试、日志和人工确认拆开设计。
常见误区：
- 把 Agent 当成万能自动化，而没有定义任务边界。
- 只优化 prompt，不设计工具权限和失败恢复。
- 让模型直接决定高风险动作，例如删除、付款、发布。