娱乐盒子
79.37M · 2026-03-10
ljq@GitHub
近期在工作闲暇之余一直在反思Agent开发以及相关的方向，Agent智能体开发难吗？在行业不断制造各种概念的今天，说难也难，难在模型本身概率输出的不可控属性，说简单大道至简，一语道破的话，核心就是Prompt的架构艺术。行业造了那么多概念，其实都是围绕着上下文工程展开，开发者还是要守正出奇，多透过现象看本质，不要为了AI而AI让自己陷入拿着锤子找钉子的定式思维模式，也不要过度信任概率模型的能力。
️注意事项：因为是随笔，过于啰嗦，且模型和微调技术发展迭代较快，部分技术时效性上可能存在偏差，以下也只作主流方向和技术性解读。
现阶段的Agent智能体应用更多是在预设可控的工具的条件下，实现的一种通过大模型参与决策和执行具体预定任务的交互型应用。
从*奥卡姆剃刀定律（如无必要，勿增实体）*角度以及从经济和实用性的角度来说，尽量选择单智能体，避免多智能体的方案，一个是token的消耗问题，还有一个是低耦合降低应用的复杂度。
一个好的Agent设计首先要考虑的就是具备非侵入性设计，非侵入性设计（Non-intrusive Design）是构建高可用、可持续演进的企业级 Agent 系统的核心原则：薄模型层，厚应用层。
这样做的优点很多：
1.低耦合与迭代空间： 将模型推理与业务逻辑解耦，确保底层模型升级或替换时，无需重构上层应用代码。
2.低成本与高扩展性： 通过配置化而非硬编码或微调来适应新场景，显著降低开发与维护成本，支持快速业务扩展。
3.经济性与基座无关： 避免供应商锁定，支持根据任务难度动态路由至不同性价比的模型，灵活应对价格波动。
4.多智能体协作灵活性： 基于标准协议通信，便于构建松耦合的多智能体网络，支持独立灰度发布、A/B测试及故障隔离。
5.顺应厂商设计哲学： 契合如 Anthropic 等厂商推崇的“上下文工程”与标准工具调用理念，最大化利用模型原生通用能力。
6.可观测性与调试透明： 决策路径、工具参数及思维链显式记录于应用层，像传统软件一样可逐行追踪和定位错误。
7.数据安全与隐私合规： 在应用层实现数据脱敏与过滤，确保敏感信息不直接暴露给模型，满足各国监管部门等合规要求。
8.确定性控制与护栏机制： 在模型输出与执行动作间插入中间件校验（如格式检查、敏感词过滤），确保系统鲁棒性。
9.知识更新实时性： 结合 RAG 技术，知识库变更秒级生效，无需重新训练模型即可回答最新业务问题。
10.长尾场景泛化能力： 保持模型通用推理能力，通过动态组装工具应对未见过的复杂或长尾场景，避免过拟合。
...
随着大语言模型（LLM）能力的飞速发展，AI 智能体（Agent）已经成为连接模型与现实世界的关键桥梁。一个典型的 Agent 不仅要能“思考”，还要能“行动”——调用外部工具获取信息、执行操作，最终完成复杂任务。然而，如何让模型在推理过程中动态地决定调用哪个工具、如何确保调用的顺序与安全性、如何高效地与后端服务交互，这些正是 Agent 开发的核心挑战。
以下将日常开发中的疑问以及难点进行系统化拆解，从最基础的 ReAct 模式开始，逐步深入到 Function Calling、MCP（模型上下文协议）、Skills 等进阶概念，梳理出一套完整的 AI Agent 开发流程，帮助开发者理解从“提示词工程”到“自主智能体”的演进路径。
ReAct（Reason + Act）是让模型具备工具调用能力的最经典范式。它的核心思想是通过提示词引导模型交替进行“推理”和“行动”，形成一个闭环：
一个典型的 ReAct 提示词模板如下：
你是一个智能助手，可以调用以下工具：
- get_weather(location: string): 获取指定城市的天气。
- search_hotel(city: string): 搜索某城市的酒店。
请按照以下格式输出：
思考：...（你的推理过程）
行动：工具名[参数]
这种方式的优点是灵活、无需模型原生支持，但缺点是需要开发者自行解析模型输出的文本，且模型可能输出不规范导致解析失败。
为了解决 ReAct 模式的不稳定性，主流模型厂商（如 OpenAI、Anthropic）推出了 Function Calling（又称 Tool Calling）功能。它的核心思想是：在 API 请求中通过 JSON 结构明确描述可用工具，模型在需要时直接返回一个结构化的 JSON 对象，而非混在文本中。
工具描述示例（JSON）：
{
"name": "get_weather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"location": { "type": "string", "description": "城市名称" }
},
"required": ["location"]
}
}
模型返回的调用指令也是结构化的，例如：
{
"tool_calls": [{
"function": {
"name": "get_weather",
"arguments": "{"location":"北京"}"
}
}]
}
无论是 ReAct 还是 Function Calling，模型接收到的都是一段文本（JSON/YAML/TOML 等格式）。模型并非像传统程序那样“解析” JSON，而是将整个文本切分成 token，利用其在大规模预训练中习得的语义理解能力去“读懂”其中的结构含义。
例如，模型知道 "name" 后面跟着的是工具名，"description" 是对工具功能的解释。这种语义理解能力使得模型能够根据用户问题与工具描述的匹配程度做出调用决策。
早期的简单实现可能依赖关键词匹配：用户输入中出现“天气”就触发天气查询。这种方式在处理同义词、复杂意图或多步推理时无能为力，例如“明天适合穿什么衣服？”隐含了天气查询需求，但并未直接出现“天气”。
现代 Agent 利用模型本身的语义理解能力进行工具选择，过程如下：
这一过程完全是模型内在的推理，无需人工规则。
以查询天气为例，完整流程如下：
get_weather，并生成参数 {"location": "北京"}。将工具暴露给模型可能带来安全风险，必须建立多层防御：
ReAct 和 Function Calling 都会消耗大量 token（特别是历史记录累积）。优化策略包括：
MCP（Model Context Protocol）是由 Anthropic 提出的开放协议，旨在解决工具接入的碎片化问题。它定义了工具的标准格式和通信方式，让模型能够以统一的方式调用任何符合 MCP 标准的服务。
MCP 的角色：
在 MCP 架构中，模型返回的 tool_calls 由 MCP Client 转发给对应的 MCP Server 执行，结果再返回给模型。
即使有了工具，模型在处理复杂任务时仍可能不知道正确的调用顺序。Skills 正是为此而生——它是一个模块化的“能力包”，包含：
Skills 的运作流程：
Skills 解决了“执行顺序”和“模块化”问题，让模型能够遵循专家级流程完成复杂任务。
结合 MCP 和 Skills，一个完整的 Agent 工作流如下：
financial_analysis 技能，加载其 SKILL.md。get_stock_data → calculate_ratios → generate_charts）。现代 Agent 需要处理图像、文档等多模态数据。当用户上传图片时，系统通常通过两种方式传递给模型：
模型后端通过视觉编码器（如 ViT）将图像转换为视觉 token，再与文本 token 拼接，利用跨模态注意力机制理解图文关系。这一过程对开发者透明，但需要注意不同模型对图像尺寸、格式的限制。
作为开发者会自然有个疑问：“能否让模型自己生成工具函数并执行？”，这正是 Agent 的未来方向之一。 目前已有探索（如代码解释器、ToolMaker），但面临安全性和可控性挑战。解决方案包括：
这相当于让模型从“使用工具”进化为“创造工具”，但必须在严格的安全边界内，重点是限定责任主体，要解决安全和可控的问题。
回顾整个过程会发现：无论采用 ReAct、Function Calling、MCP 还是 Skills，所有工作的最终产出都是一个被精心构造的 Prompt。这个 Prompt 包含了任务描述、工具说明书、执行流程指南，全部以文本形式输入给模型。模型的理解能力决定了 Agent 的成败，而开发者的价值在于通过 Prompt 工程最大化发挥模型的能力。
企业业务落地的关键典型场景之一就是企业数据的处理，Text2SQL几乎是不可绕过的关键部分，接下来讲针对数据处理的技术细节阐述。 ️补充说明：为方便理解重点部分，会省去基础安全以及认证相关的细节，围绕Text2SQL（NL2SQL）进行原理解构。Text2SQL的实现方案有很多，以下只提供一种简单可行的思路参考。
随着大语言模型（LLM）能力的不断增强，智能体（Agent）应用正从简单的问答向自主执行复杂任务演进。在这一过程中，模型需要将内在的推理能力与外部工具（如数据库、API）结合，形成“思考-行动-观察”的闭环。然而，如何清晰地呈现模型的推理过程？如何确保自然语言到数据库查询（Text-to-SQL）的准确转换？当操作从查询扩展到数据修改时，又如何守住安全底线？本文将从这三个核心问题出发，循序渐进地探讨大模型智能体在数据库操作场景下的设计原则与最佳实践。
可以把模型自身推理比作汽车的引擎——它提供动力（理解、生成、逻辑能力），而 ReAct 模式则是方向盘和路线图——它规定了解问题的宏观结构（思考→行动→观察→再思考）。没有引擎，方向盘毫无意义；没有方向盘，引擎只能直线前进，无法应对复杂路况。
在实践中，ReAct 模式通过提示词（prompt）将模型的自由推理引导至预设的轨道上，让模型不仅“想”，还能“做”。
为了让用户既了解进度又不被技术细节淹没，我们采用分层呈现原则：
这种设计使用户能感知智能体的工作进度，同时保持对话的简洁性。
将自然语言转换为 SQL 查询（Text-to-SQL）是数据库智能体的核心能力，但也面临四大挑战：
prod_cd 代表产品代码）。模型需准确映射到正确的表和字段。ReAct 模式通过“推理-行动-观察”循环，将 Text-to-SQL 分解为多个可控步骤：
模型内部先进行显式推理：
模型不必记忆整个数据库结构，而是通过工具动态查询：
get_table_schema("products") 查看 products 表字段。category_id 和 category_name，从而确定如何关联类别表。模型生成 SQL 后，进入验证阶段：
validate_sql_syntax(sql) 检查语法。EXPLAIN 或采样查询，提前发现问题。当执行结果不符合预期时，模型主动引导用户补充信息，进入下一轮推理。
对于查询（SELECT），即使 SQL 出错，最坏结果也只是查不到数据；但对于写操作（INSERT/UPDATE/DELETE），一旦出错可能导致数据污染、误删甚至业务瘫痪。因此，写操作必须采用更为严格的安全方案。
绝不让模型直接执行写操作 SQL。模型应扮演“智能解析器”角色，负责理解意图和提取参数，而最终执行权由受控的后端代码和人工审批流程掌控。
为模型分配的数据库账号默认只有 SELECT 权限，从物理上杜绝写操作。写操作必须通过专门的后端 API 进行。
不让模型拼接 SQL，而是让模型输出结构化的意图 JSON：
{
"action": "update_order_status",
"order_id": "12345",
"new_status": "已发货"
}
后端接收到 JSON 后，通过预编译的、参数化的 SQL 执行修改。这样 SQL 结构固定，模型只能影响参数值，大大降低了风险。
对于高风险操作，执行前生成修改前后的数据对比，要求用户点击“确认修改”后才真正提交。这属于关键的人机协同环节。
利用数据库事务特性：
BEGIN）ROLLBACK），确认无误后提交（COMMIT）对于极敏感操作（如删除用户、批量调价），接入正式审批流程，需主管或管理员审批通过后，后端才执行。
记录所有由模型触发的数据库操作，包括操作人、自然语言原文、生成的 SQL/JSON、执行时间、影响行数等，便于追溯和审计。
通过这一流程，模型实现了智能解析，而安全底线由可控的后端和人工把关共同守护。
大模型智能体的魅力在于将强大的内在推理能力与外部工具结合，从而完成复杂任务。在数据库操作场景中，我们通过 ReAct 模式将模型推理结构化，通过分层呈现让用户理解智能体的工作过程，通过读写分离与审批机制确保数据安全。
未来，随着模型能力的提升和工具的成熟，我们可以期待：
从思考到执行，每一步都需要精心设计。只有当推理透明、行动可控、安全到位时，大模型智能体才能真正成为值得信赖的数据助手。
其实Agent从技术开发的角度来说没什么太多神秘的东西，行业迄今造了那么多规范和概念，核心围绕一点：系统化告诉大模型需求，发挥大模型的 “思维引擎” 能力尝试去理解人类的需求，仅此而已。
切记一点：不要为了模型而模型，绝大部分任务的执行还是要靠传统业务的健壮性支撑，AI不是万能药，这是AI难以彻底替代程序员的核心原因，远离互联网上的眼球流量经济聒噪，讲更多精力放在AI工程化上才是普通程序员避免焦虑的最佳方式之一。
AI Agent 的开发是一个从“让模型能调用工具”到“让模型会规划任务”的演进过程。从 ReAct 的简单循环，到 Function Calling 的结构化交互，再到 MCP 和 Skills 带来的标准化与模块化，每一步都在让智能体更加自主、可靠、高效。
未来，随着模型能力的提升和安全机制的发展，Agent 将能够动态创造工具、自主适应新环境，成为真正的通用问题解决者。而开发者需要持续关注 Prompt 设计的艺术与工程实践的平衡，多总结模型在通用性设计上的规律和考量，在释放模型潜力的同时守住安全与可控的底线。
附原文地址
