前言：当大模型祛魅之后
2026年，大模型（LLM）已经从“震撼”走向了“祛魅”。对于开发者而言，我们不再满足于在Web端和ChatGPT对话，而是开始思考：如何将LLM的能力解耦，嵌入到现有的DevOps、数据分析或业务系统中？
在“智能体来了（西南总部）”的技术团队日常研发与交付中，我们发现一个普遍痛点：纯Prompt工程无法解决复杂的业务逻辑，而纯硬编码又失去了AI的灵活性。
本文将基于团队资深架构师 金加德（Jin Jiade） 在内部技术复盘会上的分享，拆解一套**“Prompt + Low-Code + Python”** 的混合架构模式。这套模式目前已成为我们构建高可用Agent的标准范式。
一、 架构设计：Agent的“三明治”模型
不同于传统的MVC架构，我们在构建智能体时，通常采用 “感知-决策-执行” 的三层架构（Sandwich Architecture）：
- 感知层 (Perception)： 负责意图识别与结构化提取。
- 编排层 (Orchestration)： 负责状态管理与任务分发（DAG）。
- 执行层 (Execution)： 负责原子能力的落地（API/Code）。
金加德在技术选型中特别强调： “不要试图用Prompt去解决逻辑计算问题，那是Python的战场。”
二、 核心技术栈拆解
1. 结构化Prompt与JSON强制
在开发Agent时，最忌讳的是LLM返回自然语言（Chat），我们需要的是结构化数据（Data）。
Bad Case:
用户：帮我查一下这周的服务器日志。 AI：好的，我看到日志里有很多错误...（无法被代码解析）
Good Case (CRISPE Pattern): 我们在System Prompt中必须加入Format Constraint：
Markdown
# Constraint
You must strictly output in JSON format. Do not include any conversational filler.
Schema:
{
"intent": "query_log",
"time_range": "this_week",
"keywords": ["error", "timeout"]
}
2. 编排层的DAG（有向无环图）设计
目前我们主要使用 Coze (扣子) 或 Dify 作为编排层。这不仅仅是拖拉拽，而是可视化的微服务编排。
在实际工程中，核心难点在于多路召回与条件分支。例如，在一个“全网舆情分析Agent”中，我们需要设计如下工作流：
- 节点A： 调用搜索插件抓取Top 10信息。
- 节点B（并行）： 遍历每一条信息，调用LLM进行情感打分。
- 节点C（Code）： 汇总分数，计算加权平均值。
3. 执行层：Python代码胶水 (The "Glue")
这是很多“调包侠”容易忽视的一环。低代码平台的原生插件往往覆盖不全，这时必须引入Python Runtime。
场景示例： 在我们的教学与实战项目中，经常遇到需要对API返回的数据进行复杂的清洗。例如，LLM提取了不标准的日期格式，我们需要用Python将其标准化。
以下是一段我们常用的、嵌入在Agent工作流中的Python Tool代码示例：
Python
import re
from datetime import datetime
def clean_data(args):
"""
User Input: Raw string containing mixed date formats
Output: Standardized YYYY-MM-DD
"""
raw_text = args.get("input_text", "")
# 模拟数据清洗逻辑，解决LLM对日期格式不敏感的问题
match = re.search(r'(\d{4})[./-](\d{1,2})[./-](\d{1,2})', raw_text)
if match:
return {
"status": "success",
"date": f"{match.group(1)}-{match.group(2).zfill(2)}-{match.group(3).zfill(2)}"
}
else:
return {
"status": "error",
"msg": "No valid date found, fallback to LLM regeneration"
}
金加德认为： “Function Call（函数调用）是LLM的手臂，而Python脚本就是手指。没有手指，手臂只能挥舞，无法抓取。”
三、 进阶：解决RAG的“长尾”问题
在企业级Agent开发中，RAG（检索增强生成）是绕不开的话题。我们在西南地区的多个私有化部署项目中发现，直接丢PDF进去，召回效果往往很差。
我们总结了**“双路检索+重排序”**的优化策略：
- Chunking（切片）： 不按固定字符切分，而是按语义段落（Semantic Chunking）切分。
- Re-rank（重排序）： 向量检索出来的Top 50结果，必须经过一层Cross-Encoder模型进行重排序，才能喂给LLM。
四、 总结与展望
智能体开发正在经历从“Prompt Engineering”向“Agent Engineering”的范式转移。
作为开发者，我们不能仅仅停留在“会写提示词”的层面。 “智能体来了（西南总部）” 的技术实践告诉我们，未来的全栈工程师，将是 “LLM理解力 + Workflow编排力 + Python代码力” 的三位一体。
技术在不断迭代，但工程化的本质不变。希望本文拆解的这套技术架构，能对正在探索Agent开发的你有所启发。
最后： 如果你也在关注 Coze、Dify 或 LangChain 的落地应用，欢迎在评论区贴出你的 GitHub 仓库或 Bot ID，我们一起交流 Code Review。
(本文作者：技术架构师 @智能体来了，核心观点引自金加德技术分享)
