作者主页编程的一拳超人⛺️ 欢迎关注点赞 留言 收藏 于高山之巅方见大河奔涌于群峰之上更觉长风浩荡。专栏系列C AI Agent 实战 / 大模型工具调用 / 智能编程助手⭐如果本文对你有帮助欢迎点赞、收藏、关注三连支持问题交流评论区留言或私信看到必回C 手写 AI 编程 Agent1AI Agent 概念入门与 ReAct 架构设计1. 什么是 AI Agent1.1 Agent 与普通 Chatbot 的区别1.2 ReAct 范式详解Reasoning Acting1.3 Tool Use Protocol 概念1.4 Agent 思考循环图解1.5 Agent 发展简史1.6 主流 Agent 框架对比1.7 C 实现 vs Python 实现详细对比1.8 Agent 能力分级L1-L51.9 C 实现 Agent 的独特价值1.10 主流 Agent 架构模式分类2. 技术架构设计2.1 完整架构图2.2 核心循环详解2.3 消息协议设计2.4 工具注册与发现机制2.5 状态管理 系列目录C 手写 AI 编程 Agent1AI Agent 概念入门与 ReAct 架构设计适用标准C17 |难度入门 |阅读时间约 15 分钟本文是「C 手写 AI 编程 Agent」12篇系列的第1篇建立概念基础。1. 什么是 AI Agent1.1 Agent 与普通 Chatbot 的区别普通的 Chatbot聊天机器人本质上是一个文本接龙机器你给它一段输入它返回一段输出整个过程是单轮、无状态、无行动力的。而 AI Agent 则完全不同——它是一个能够自主思考、使用工具、与环境交互的智能体。特性普通 ChatbotAI Agent交互模式单轮问答多轮思考行动循环外部能力无可调用工具文件、编译器、Shell等状态管理无/简单上下文完整的对话历史任务状态错误处理无法自我修正观察结果→反思→重试目标导向被动响应主动规划并执行自主性低高在约束范围内自主决策一个直观的比喻Chatbot 像一个只会回答问题的百科全书而 Agent 更像一个能动手干活的工程师——它不仅能告诉你怎么做还能自己去做、检查结果、发现问题后自行修复。1.2 ReAct 范式详解Reasoning ActingReAct 是当前主流 AI Agent 的核心思维范式由 Yao et al. (2022) 提出。其核心思想是将**推理Reasoning和行动Acting**交替进行Thought: 我需要先了解项目的目录结构才能确定在哪里创建新文件。 Action: list_directory(path.) Observation: [src/, include/, tests/, CMakeLists.txt, README.md] Thought: 项目使用标准 CMake 布局。新文件应该放在 src/ 目录下。 Action: write_file(pathsrc/calculator.cpp, content...) Observation: File written successfully (256 bytes) Thought: 文件已创建现在需要将其添加到 CMakeLists.txt 中并编译验证。 Action: compile(targetmyproject) Observation: Build succeeded. Thought: 编译通过任务完成。 Final Answer: 已成功创建 calculator.cpp 并通过编译验证。ReAct 的关键优势在于推理引导行动每一步行动都有明确的思考依据观察修正推理根据实际执行结果调整后续计划可追溯性完整的思考链便于调试和理解容错能力失败时能分析原因并尝试替代方案1.3 Tool Use Protocol 概念Tool Use Protocol工具使用协议定义了 LLM 如何声明、选择和调用外部工具。现代 LLM API如 OpenAI、Anthropic、Google都提供了原生的 Function Calling / Tool Use 支持。核心流程定义阶段向 LLM 描述可用工具的名称、功能、参数格式JSON Schema选择阶段LLM 根据当前任务决定是否需要调用工具以及调用哪个调用阶段LLM 生成结构化的工具调用请求函数名参数执行阶段宿主程序解析请求执行对应操作返回结果反馈阶段将执行结果作为消息回传给 LLM继续下一轮思考1.4 Agent 思考循环图解┌─────────────────────────────────────────────────────┐ │ Agent 思考循环 │ │ │ │ ┌──────────┐ │ │ │ User │ │ │ │ Input │ │ │ └────┬─────┘ │ │ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Think │◄──►│ Select │◄──►│ Execute │ │ │ │(LLM推理) │ │ Tool │ │ Tool │ │ │ └────┬─────┘ └──────────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌──────────┐ │ │ │ ├────────►│ Observe │◄──────────┘ │ │ │ │ (结果) │ │ │ │ └────┬─────┘ │ │ │ │ │ │ │ ┌─────────▼─────────┐ │ │ │ │ Need more action? │ │ │ │ └────┬────────┬─────┘ │ │ │ YES│ │NO │ │ │ ▼ ▼ │ │ │ (回到Think) ┌──────────┐ │ │ │ │ Complete │ │ │ │ │ Response │ │ │ │ └──────────┘ │ │ ▼ │ │ ┌──────────┐ │ │ │ Output │ │ │ │ to User │ │ │ └──────────┘ │ └─────────────────────────────────────────────────────┘1.5 Agent 发展简史AI Agent 的概念并非一夜之间诞生而是经历了从理论到实践的漫长演进。了解这段历史有助于我们理解当前 Agent 技术的设计哲学和发展方向。时间里程碑核心贡献局限性2022.10ReAct 论文发表Yao et al. 提出 ReasoningActing 范式奠定现代 Agent 理论基础仅停留在学术研究层面2023.03AutoGPT 发布首个引爆社区的自主 Agent 项目展示了 LLM 自主循环的可能性稳定性差、缺乏工具生态、容易陷入死循环2023.04BabyAGI引入任务队列和优先级排序简化了 Agent 架构功能单一实际可用性低2023.06LangChain Agents提供了标准化的 Agent 框架和工具集成方案抽象层过厚调试困难2023.09OpenAI Function CallingLLM 原生支持结构化工具调用大幅提升可靠性依赖特定 API不够通用2023.11AutoGen (Microsoft)多 Agent 对话框架支持人机协作配置复杂学习曲线陡峭2024.01CrewAI面向角色分工的多 Agent 编排框架灵活性受限于预定义角色2024.03Devin (Cognition)首个AI 软件工程师具备完整的开发环境交互能力闭源、价格昂贵、实际效果有争议2024.06Claude Code / Cursor AgentIDE 级别的编码 Agent深度集成开发工作流依赖特定 IDE 生态2024.11Anthropic MCP 协议标准化工具/数据源连接协议推动工具互操作性生态尚在早期建设阶段2025.01Claude Agent SDKAnthropic 官方 Agent 构建工具包提供生产级基础设施绑定 Claude 模型生态2025~至今Agent 百花齐放OpenAI Codex Agent、Google Jules、各类开源 Agent 涌现标准化不足、安全挑战突出关键洞察Agent 的发展轨迹清晰地呈现出三个趋势——从演示到实用、从单 Agent到多 Agent 协作、从私有协议到开放标准MCP。C 开发者在这一浪潮中的独特机会在于将 Agent 能力嵌入高性能系统和传统软件生态中。1.6 主流 Agent 框架对比在选择或自建 Agent 框架之前有必要了解当前主流方案的优劣。以下对比涵盖了 Python 生态中最具影响力的框架以及 C 自研方案特性LangChainAutoGenCrewAIClaude Agent SDKC 自研本教程语言PythonPythonPythonPython/TSC学习曲线中等较高较低中等较高单 Agent 能力⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐多 Agent 协作⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐需自建工具生态⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐需自建执行性能⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐类型安全❌❌❌部分✅部署复杂度高Python 环境高中中低单二进制系统集成一般一般一般较好极佳调试友好度较差中等较好好取决于实现适用场景通用原型验证多 Agent 研究角色扮演/流程编排Claude 生态应用嵌入式/高性能/系统级社区活跃度极高高中高快速增长无自维护选型建议如果你需要快速验证想法选 LangChain/CrewAI如果你构建多 Agent 研究系统选 AutoGen如果你在 Claude 生态内开发选 Claude Agent SDK如果你需要将 Agent 嵌入 C 系统、追求极致性能或深入理解底层原理那么本教程的 C 自研方案正是你需要的。1.7 C 实现 vs Python 实现详细对比为了帮助读者做出更明智的技术选型以下是两种实现路线在多个维度上的深入对比对比维度C 实现Python 实现评价启动速度毫秒级编译后直接运行秒级解释器依赖加载C 胜内存占用10-50 MB200-500 MBC 胜工具执行效率原生系统调用零开销subprocess/os 模块有额外开销C 胜LLM API 调用cpr/libcurl性能优秀requests/httpx足够用平手瓶颈在网络JSON 处理nlohmann/json编译期优化内置 json 模块运行时解析C 略胜开发速度较慢需手动管理更多细节快框架封装完善Python 胜生态丰富度有限需自行实现很多组件极其丰富开箱即用Python 大胜并发模型多线程/std::async/io_uringasyncio/多线程/GIL 限制C 胜错误诊断编译期捕获大量错误运行时才发现类型/逻辑错误C 胜可嵌入性可作为库嵌入任何 C 项目需要 Python 运行时环境C 大胜跨平台CMake 标准库良好支持天然跨平台平手热更新/动态加载困难需重新编译简单importlib/reloadPython 胜适合团队规模小到中型团队任意规模Python 胜长期维护成本代码量少但修改成本高代码量多但修改灵活视情况而定实践建议对于本教程的学习目的C 实现能让你深入理解每一个底层细节。在实际项目中一种务实的做法是用 Python 做原型验证和上层编排用 C 实现性能关键的工具层两者通过 MCP 协议或 gRPC 通信兼得开发效率和运行性能。1.8 Agent 能力分级L1-L5参照自动驾驶的分级标准我们可以将 AI Agent 的能力划分为五个等级。这个分级有助于评估当前 Agent 的水平也指明了未来的发展方向等级名称描述典型代表人类角色L1辅助级LLM 仅提供建议和知识所有操作由人类执行ChatGPT 普通对话、Copilot 补全完全主导L2工具级Agent 能调用工具执行简单任务但每步需人类确认GitHub Copilot Chat、Cursor Tab逐步确认L3自主级Agent 能自主完成明确定义的任务仅在异常时请求人类介入Claude Code、Devin、本教程实现监督审核L4协作级多个 Agent 协同工作能处理模糊需求具备规划和自我修正能力AutoGen 多 Agent、CrewAI 团队高层指导L5通用级Agent 能在开放域环境中自主学习、适应和改进接近人类专家水平尚未实现AGI 愿景平等伙伴当前行业现状大多数商用 Agent 处于L2-L3 过渡期。本教程实现的 Agent 定位为L3 级别——它能在给定工作空间内自主完成编码、编译、修复等任务但仍受限于预定义的工具集和安全边界。各等级的关键技术门槛L1→L2Function Calling / Tool Use 协议的可靠实现L2→L3自主思考循环 错误自修复 安全防护L3→L4多 Agent 协调 长期记忆 任务规划L4→L5自主学习 元认知 开放域推理前沿研究课题1.9 C 实现 Agent 的独特价值为什么选择 C 而不是 Python 来实现 AI Agent极致性能工具执行尤其是编译、文件IO是 CPU/IO 密集型操作C 的原生性能优势显著系统级访问直接操作文件系统、进程、内存无需中间层嵌入式场景可将 Agent 嵌入到 IDE 插件、游戏引擎、EDA 工具等 C 生态中类型安全编译期检查减少运行时错误对于需要高可靠性的 Agent 尤为重要学习价值深入理解 Agent 底层机制而非停留在框架抽象层零依赖部署编译为单一二进制文件无需运行时环境当然C 也有劣势开发速度较慢、生态不如 Python 丰富。本教程选择的库nlohmann/json、cpr、fmt都是 header-only 或易于集成的尽量降低开发负担。1.10 主流 Agent 架构模式分类除了 ReAct 范式之外学术界和工业界还提出了多种 Agent 架构模式。理解这些模式有助于在不同场景下选择最合适的方案架构模式核心思想优势劣势适用场景ReAct推理与行动交替进行灵活、可追溯、容错每步都需 LLM 调用延迟较高通用任务、交互式编程Plan-and-Execute先制定完整计划再逐步执行全局视角、减少无效探索计划可能与实际脱节、规划本身消耗 token复杂多步骤任务、项目重构Reflexion执行后自我反思积累经验教训能从失败中学习、持续改进需要额外 LLM 调用做反思反复试错型任务、代码调试LATS树搜索 反思 价值评估系统性探索解空间计算开销大、实现复杂数学推理、创意生成AutoGPT-style完全自主的任务分解与执行循环高度自主容易失控、难以调试研究探索、概念验证Multi-Agent Debate多个 Agent 从不同角度辩论提高决策质量、减少幻觉通信开销大、收敛慢代码审查、方案设计Human-in-the-Loop关键节点暂停等待人类确认安全可控、结合人类判断打断自动化流程、依赖人类响应生产环境、高风险操作┌─────────────────────────────────────────────────────────────┐ │ Agent 架构模式选择决策树 │ │ │ │ 任务复杂度低 ─── YES ──→ ReAct简单直接 │ │ │NO │ │ ▼ │ │ 需要全局规划 ─── YES ──→ Plan-and-Execute │ │ │NO │ │ ▼ │ │ 允许试错学习 ─── YES ──→ Reflexion │ │ │NO │ │ ▼ │ │ 需要多角度验证 ── YES ──→ Multi-Agent Debate │ │ │NO │ │ ▼ │ │ 高风险操作 ──── YES ──→ Human-in-the-Loop │ │ │NO │ │ ▼ │ │ 默认 → ReAct 安全防护 │ └─────────────────────────────────────────────────────────────┘实践建议大多数场景下ReAct 是最佳起点。当遇到特定瓶颈时再叠加其他模式——例如在 ReAct 基础上加入 Reflexion 的自我评估环节或在复杂任务前增加 Planning 阶段。不要过度设计从简单开始按需演进。2. 技术架构设计2.1 完整架构图┌─────────────────────────────────────────────────────────────────────┐ │ C AI Agent 架构 │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 用户交互层 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌──────────────────┐ │ │ │ │ │ REPL 终端 │ │ 任务模式 │ │ 对话模式 │ │ │ │ │ └──────┬──────┘ └──────┬──────┘ └────────┬─────────┘ │ │ │ │ └─────────────────┼──────────────────┘ │ │ │ └───────────────────────────┼─────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ Agent 核心引擎 │ │ │ │ │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ │ │ │ │ Message │ │ Think Loop │ │ State │ │ │ │ │ │ Manager │ │ Controller │ │ Manager │ │ │ │ │ │ (消息管理) │ │ (思考循环) │ │ (状态管理) │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ └────────┬─────────┘ │ │ │ │ │ │ │ │ │ │ │ └─────────────────┼────────────────────┘ │ │ │ │ ▼ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ │ │ LLM Client (HTTP/API) │ │ │ │ │ │ • Function Calling 请求构造 │ │ │ │ │ │ • Streaming 响应解析 │ │ │ │ │ │ • Token 计数与窗口管理 │ │ │ │ │ │ • 错误重试与恢复 │ │ │ │ │ └──────────────────────┬───────────────────────────────┘ │ │ │ └──────────────────────────┼───────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 工具系统层 │ │ │ │ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ │ │ ToolRegistry (工具注册表) │ │ │ │ │ │ • 动态注册/注销 • JSON Schema 序列化 │ │ │ │ │ │ • 按名称查找 • 参数校验 │ │ │ │ │ └──────────────────────┬───────────────────────────────┘ │ │ │ │ ┌─────────────┼─────────────┬──────────────┐ │ │ │ │ ▼ ▼ ▼ ▼ │ │ │ │ ┌──────────────┐ ┌──────────┐ ┌───────────┐ ┌──────────┐ │ │ │ │ │ FileTools │ │Compile │ │ ShellTool │ │ Custom │ │ │ │ │ │ • read_file │ │ Tool │ │ • exec │ │ Tools │ │ │ │ │ │ • write_file │ │ • cmake │ │ • sandbox │ │ • ... │ │ │ │ │ │ • edit_file │ │ • make │ │ • timeout │ │ │ │ │ │ │ │ • list_dir │ │ • ninja │ │ │ │ │ │ │ │ │ │ • search │ │ • parse │ │ │ │ │ │ │ │ │ └──────────────┘ └──────────┘ └───────────┘ └──────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 基础设施层 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │ │ │ │ │ cpr │ │ nlohmann │ │ fmt │ │ std:: │ │ │ │ │ │ (HTTP) │ │ /json │ │ (格式化) │ │ filesystem│ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘2.2 核心循环详解Agent 的核心是一个Think-Act-Observe循环User Input → [Think → Select Tool → Execute → Observe] × N → Complete/Output关键设计决策最大迭代次数防止无限循环默认 20 次超时机制单次工具执行超时 总任务超时中间输出每轮思考和行动都实时展示给用户优雅终止LLM 返回纯文本非工具调用时视为完成2.3 消息协议设计所有消息统一使用以下结构structMessage{std::string role;// system | user | assistant | toolstd::string content;// 文本内容std::string tool_call_id;// 工具调用ID仅 tool 角色// 工具调用信息仅 assistant 角色发起工具调用时structToolCall{std::string id;std::string function_name;nlohmann::json arguments;};std::vectorToolCalltool_calls;};2.4 工具注册与发现机制采用注册表模式Registry Pattern每个工具是一个ToolDefinition结构体 一个 handler 函数启动时将所有工具注册到ToolRegistryLLM 请求时Registry 序列化为 JSON Schema 数组收到工具调用请求时Registry 按名称查找并执行 handler2.5 状态管理Agent 维护以下状态对话历史完整的 Message 列表当前任务状态idle / thinking / executing_tool / completed / error迭代计数器当前思考轮次Token 使用量累计消耗用于成本控制工作目录当前操作的根目录 系列目录✅第1篇AI Agent概念入门与ReAct架构设计当前阅读第2篇环境搭建与CMake依赖管理第3篇工具注册表与文件操作工具集第4篇编译诊断工具与Shell执行引擎第5篇工具超时缓存与链式组合模式第6篇Agent核心循环消息管理与LLM调用第7篇Token窗口管理与错误恢复策略第8篇记忆系统规划引擎与多Agent协作第9篇Prompt工程从System Prompt到AB测试第10篇主程序整合与端到端实战演示第11篇Reflexion与Tree-of-Thought等高级模式第12篇性能优化安全防护与FAQ总结➡️下一篇第2篇环境搭建与CMake依赖管理
尧图网络