Agentic Engineering
什么是Agentic Engineering
Agentic Engineering（代理工程 /
智能体工程）是指构建能够自主规划、决策和执行任务的 AI 系统的工程实践。
核心概念
什么是 "Agentic" 系统？
与传统软件按预设规则执行不同，Agentic 系统具备：
┌───────────┬───────────────────────────────────────────────────┐
│ 特性 │ 说明 │
├───────────┼───────────────────────────────────────────────────┤
│ 自主性 │ 能独立分析目标、制定计划并执行，无需人工逐步指导 │
├───────────┼───────────────────────────────────────────────────┤
│ 工具使用 │ 可调用 API、查询数据库、执行代码、操作文件等 │
├───────────┼───────────────────────────────────────────────────┤
│ 推理能力 │ 基于 LLM 进行逻辑分析、问题解决和决策 │
├───────────┼───────────────────────────────────────────────────┤
│ 记忆/状态 │ 保持上下文，从交互中学习，维护长期状态 │
├───────────┼───────────────────────────────────────────────────┤
│ 适应性 │ 面对意外情况能调整策略，而非 rigidly 遵循固定流程 │
└───────────┴───────────────────────────────────────────────────┘
与传统软件工程的对比
传统软件工程：
输入 → [固定规则/逻辑] → 输出
↓
确定性执行
Agentic Engineering：
目标 → [推理/规划] → 工具调用 → 观察结果 → 调整策略 → ...
↓ ↓
LLM 推理 与环境交互
实际例子
1. Claude Code 本身 - 能理解你的需求，自主读取文件、编辑代码、运行命令
2. 自动化研究助手 - 给定主题，自动搜索、整理、生成报告
3. 智能客服 - 不仅回答问题，还能查询订单、发起退款、协调人工
4. 代码审查 Agent - 自动分析 PR，提出修改建议，甚至直接修复问题
关键技术栈
- LLM（如 Claude、GPT）- 提供推理能力
- Tool Use / Function Calling - 与外部系统交互
- Memory 系统 - 长期记忆和上下文管理
- 多 Agent 协作 - 多个专业 Agent 分工合作
- Human-in-the-loop - 关键节点人工确认
为什么重要？
Agentic Engineering 代表了从 "AI 作为工具" 到 "AI 作为协作者" 的转变。它让软件
系统能够处理开放式、复杂、多步骤的任务，而不需要为每种情况预先编程。
---
简单说：Agentic Engineering = 让 AI
像人一样思考-行动-观察-调整，而不仅仅是执行预设指令。
如何应用Agentic Engineering
应用 Agentic Engineering 解决问题，需要分层技术栈 +
系统化的工程实践。以下是完整框架：
一、技术栈分层
1. 模型层（推理引擎）
┌───────────┬──────────────────┬──────────────────────────────────────────┐
│ 组件 │ 选择 │ 关键考量 │
├───────────┼──────────────────┼──────────────────────────────────────────┤
│ 基础模型 │ Claude/GPT/Gemin │ 推理能力 > 生成能力，支持 tool use │
│ │ i │ │
├───────────┼──────────────────┼──────────────────────────────────────────┤
│ 模型路由 │ LiteLLM, Router │ 按任务复杂度选择模型（简单任务用轻量模型 │
│ │ │ ） │
├───────────┼──────────────────┼──────────────────────────────────────────┤
│ 结构化输 │ JSON Schema, │ 强制模型输出可解析的结构化数据 │
│ 出 │ Pydantic │ │
└───────────┴──────────────────┴──────────────────────────────────────────┘
2. 工具层（Action 接口）
# 工具定义示例
tools = [
{
"name": "search_database",
"description": "查询用户订单信息",
"parameters": {
"order_id": "string, 订单号",
"fields": "array, 需要返回的字段"
}
},
{
"name": "refund_order",
"description": "发起订单退款，需要用户确认",
"parameters": {...}
}
]
常见工具类型：
- 数据工具：SQL 查询、API 调用、文件读写
- 计算工具：代码执行（Python/Node）、数学计算
- 通信工具：发送邮件、消息通知、创建工单
- 决策工具：规则引擎、风险评估、人工审批
3. 记忆层（状态管理）
┌──────────┬───────────────────────────────┬──────────────────────┐
│ 记忆类型 │ 技术实现 │ 用途 │
├──────────┼───────────────────────────────┼──────────────────────┤
│ 短期记忆 │ Conversation Buffer │ 当前对话上下文 │
├──────────┼───────────────────────────────┼──────────────────────┤
│ 工作记忆 │ 结构化存储（JSON/YAML） │ 任务执行中的中间状态 │
├──────────┼───────────────────────────────┼──────────────────────┤
│ 长期记忆 │ 向量数据库（Pinecone/Milvus） │ 历史经验、知识库检索 │
├──────────┼───────────────────────────────┼──────────────────────┤
│ 程序记忆 │ 技能库（Skill Library） │ 可复用的工具组合 │
└──────────┴───────────────────────────────┴──────────────────────┘
4. 编排层（控制流）
- ReAct 循环：推理 → 行动 → 观察 → 重复
- Plan-and-Execute：先规划步骤，再逐条执行
- 多 Agent 协作：Manager-Worker、 debate、 pipeline 模式
- 人机协作：关键决策点人工确认（HITL）
5. 监控与评估层
- Tracing：Langfuse, LangSmith, OpenTelemetry
- 评估框架：LLM-as-judge、规则检查、人工标注
- A/B 测试：不同提示/策略的效果对比
---
二、应用者需要做的事
Phase 1: 问题建模（最关键）
判断问题是否适合 Agentic 方案：
✅ 适合：
- 步骤不固定，需要动态决策（如客服、研究助手）
- 涉及多系统协作（需要查数据、调 API、发通知）
- 容错性较高，可以迭代修正
❌ 不适合：
- 确定性流程（传统 if-else 更清晰）
- 高风险操作（医疗诊断、金融交易）需严格限制
Phase 2: 设计工具集
原则：工具粒度要适中，描述要清晰
# 不好的设计
def process_everything(data): # 太粗，模型无法灵活组合
...
def add(a, b): # 太细，增加调用开销
return a + b
# 好的设计
def query_user_orders(user_id, status=None, time_range=None):
"""查询用户订单，支持按状态和时间筛选"""
...
def cancel_order(order_id, reason):
"""取消订单，会检查订单状态是否允许取消"""
...
Phase 3: 构建控制循环
# 简化的 ReAct 循环框架
class Agent:
def run(self, task):
context = {"task": task, "steps": []}
while not self.is_complete(context):
# 1. 推理下一步
action = self.llm.plan(context, self.tools)
# 2. 执行工具
observation = self.execute(action)
# 3. 更新状态
context["steps"].append({"action": action, "result": observation})
# 4. 检查是否需要人工介入
if action["type"] == "human_confirm":
return self.wait_for_human(context)
return self.generate_result(context)
Phase 4: 设计记忆策略
关键决策：
- 什么需要记住？（用户偏好、中间结果、错误经验）
- 记忆如何检索？（向量相似度、关键词、时间衰减）
- 记忆如何更新？（覆盖、追加、版本化）
Phase 5: 安全防护（必须）
┌──────────┬────────────────────────────────┐
│ 风险 │ 防护措施 │
├──────────┼────────────────────────────────┤
│ 工具滥用 │ 权限控制、操作白名单、速率限制 │
├──────────┼────────────────────────────────┤
│ 无限循环 │ 最大步数限制、超时机制 │
├──────────┼────────────────────────────────┤
│ 幻觉 │ 工具结果校验、置信度阈值 │
├──────────┼────────────────────────────────┤
│ 数据泄露 │ 敏感信息脱敏、审计日志 │
└──────────┴────────────────────────────────┘
Phase 6: 评估与迭代
建立评估集：
test_cases:
- input: "帮我查昨天下的订单为什么还没发货"
expected_tools: ["query_recent_orders", "check_shipment_status"]
expected_outcome: "返回订单号和物流状态"
- input: "我要退款"
expected_tools: ["query_eligible_orders", "initiate_refund"]
requires_human_confirm: true
监控指标：
- 任务完成率
- 平均步数/耗时
- 工具调用准确率
- 人工介入率
---
三、典型架构示例
┌─────────────────────────────────────────┐
│ User Interface │
└─────────────────┬───────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Orchestrator (ReAct / Plan-Execute) │
│ - 任务分解 │
│ - 状态管理 │
│ - 循环控制 │
└─────────────────┬───────────────────────┘
▼
┌─────────────────────────────────────────┐
│ LLM Core (Claude/GPT) │
│ - 推理决策 │
│ - 工具选择 │
│ - 结果生成 │
└─────────────────┬───────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Tool Registry │
│ ├─ Data Tools (SQL/API) │
│ ├─ Action Tools (Write/Notify) │
│ └─ Compute Tools (Code/Search) │
└─────────────────────────────────────────┘
▼
┌─────────────────────────────────────────┐
│ Memory Store │
│ ├─ Short-term: Redis/Context │
│ ├─ Long-term: Vector DB │
│ └─ Skill Library: File/DB │
└─────────────────────────────────────────┘
---
四、快速启动建议
1. 从简单开始：先用 2-3 个工具 + ReAct 循环跑通一个场景
2. 观察失败模式：记录 Agent 出错的情况，针对性优化提示或工具
3. 逐步放权：初期所有操作需确认，稳定后再开放自动执行
4. 建立回退机制：Agent 卡住时能优雅降级到人工处理
浙公网安备 33010602011771号