1. 为什么“会调API”和“能跑Agent”是两码事
这两年我接触过不少团队，几乎每个做AI应用的都在聊Agent。但真正把Agent跑在生产环境里的人都知道，从“写个demo让模型调用一次工具”到“构建一套稳定、可观测、可扩展的Agent Runtime”，中间隔着的不是一层封装，而是一整套工程体系。很多人第一次做Agent编排时，脑子里想的是“不就是让模型输出JSON然后我解析执行吗”，结果上线三天就被各种超时、死循环、上下文爆炸、工具调用失败给教做人了。
Agent编排技术全景这个话题，本质上要回答三个问题：Agent Runtime到底由哪些核心模块组成？每个模块在工程上最容易踩的坑是什么？以及，怎么把这些模块拼成一套真正能扛住真实流量的系统。这篇文章我会从底层原理讲到工程落地，把我在实际项目里趟过的路、踩过的坑、以及那些文档里不会写的细节都摊开讲。适合已经写过基础Agent demo、准备往生产级方向推进的开发者，也适合正在做技术选型的架构师参考。
先说一个我自己的判断：Agent Runtime的核心难点从来不是“让模型思考”，而是“让模型在受控的环境里可靠地行动”。思考是模型的事，行动是Runtime的事。把这两件事分清楚，后面的设计思路就顺了。
2. Agent Runtime的底层原理拆解
2.1 从ReAct到Plan-Execute：编排范式的演进逻辑
最早大家做Agent，基本都是从ReAct范式起步的。ReAct的核心是“思考-行动-观察”的循环：模型先输出一段推理，然后决定调用哪个工具，拿到工具返回结果后再继续推理，直到任务完成。这个范式的好处是简单直观，每一步都有明确的输入输出，调试起来也相对容易。
但ReAct有个致命问题：它没有全局规划能力。模型每一步都是局部最优决策，走着走着就偏了。我见过一个典型场景：让Agent去查一份文档里的三个数据点然后做汇总，ReAct模式下模型查完第一个点就忘了原始任务是什么，开始漫无目的地探索。这不是模型能力问题，是范式本身的局限——它没有“任务状态”的概念。
于是就有了Plan-Execute范式。这个范式先让模型生成一个完整的执行计划，把任务拆成有序的步骤列表，然后逐步执行。执行过程中如果某一步失败，可以回退到计划层重新规划。这个思路更接近人类做事的方式：先想清楚要干什么，再动手。
但Plan-Execute也不是银弹。它的缺点是计划一旦生成就相对僵化，遇到需要动态调整的场景反应不够灵活。所以现在主流的做法是混合编排：用Plan-Execute做顶层任务分解，用ReAct做子任务的灵活执行。具体来说，Runtime维护一个任务队列，每个任务节点可以是“规划型”也可以是“执行型”，规划型节点负责拆解，执行型节点负责用ReAct循环完成具体动作。
这里有个关键设计决策：任务状态存在哪里。我的经验是，状态必须外置到Runtime层，不能依赖模型的上下文窗口来“记住”。原因很简单，上下文窗口是有限且昂贵的资源，而任务状态可能需要在多个Agent之间传递、需要持久化、需要支持断点续跑。把状态放在Runtime的State Store里，模型每次只拿到当前步骤需要的最小上下文，这样既省token又稳定。
2.2 上下文工程：Agent Runtime的隐形战场
如果说编排范式是Agent的骨架，那上下文工程就是它的血液循环系统。我敢说，80%的Agent线上问题都跟上下文管理有关。
上下文工程要解决的核心矛盾是：模型需要足够的信息来做决策，但上下文窗口是有限且昂贵的。这个矛盾在单轮对话里不明显，但在Agent场景下会被急剧放大——因为Agent的每一步行动都会产生新的观察结果，这些结果如果全部塞回上下文，很快就会撑爆窗口。
我的做法是把上下文分成四层来管理：
- 系统层：Agent的角色定义、能力边界、输出格式约束。这部分是静态的，每次请求都带上，但内容要极度精简。我见过有人把几千字的系统提示词塞进去，结果模型注意力被稀释，关键指令反而被忽略。
- 任务层：当前任务的描述、已完成的步骤摘要、当前步骤的详细指令。这部分是动态的，但要做压缩。我的经验是，已完成的步骤不要保留原始对话，而是让模型生成一句摘要，只保留摘要。
- 工具层：当前可用的工具列表及其参数说明。这里有个技巧：不要一次性把所有工具都暴露给模型，而是根据当前任务阶段动态筛选。工具太多会让模型选择困难，也浪费token。
- 记忆层：跨会话的长期记忆，比如用户偏好、历史任务结果。这部分通常用向量检索来按需召回，而不是全量加载。
实操心得：上下文压缩不要用简单的截断，要用“摘要+关键实体保留”的方式。我试过直接截断，结果模型丢失了关键的任务约束条件，导致执行偏离。后来改成让模型对历史步骤做结构化摘要，保留任务ID、关键参数、执行结果状态，效果稳定很多。
2.3 工具调用的可靠性设计：从“能调”到“调得稳”
工具调用是Agent与外部世界交互的唯一通道，它的可靠性直接决定了Agent能不能用。我见过太多demo里工具调用一次成功就以为万事大吉，结果生产环境里网络抖动、参数格式错误、工具返回超时各种问题全来了。
工具调用的可靠性设计要覆盖三个层面：
第一层是参数校验。模型输出的工具参数不能直接信任，必须做schema校验。我习惯用JSON Schema定义每个工具的参数规范，模型输出后先过一遍校验，不通过就返回错误信息让模型重新生成。这里有个细节：错误信息要具体，告诉模型哪个字段错了、期望什么格式，而不是笼统地说“参数错误”。
第二层是执行容错。工具执行可能失败，失败后要有重试策略。但重试不是无脑重试，要区分错误类型：网络超时可以重试，参数错误重试也没用，业务逻辑错误需要上报。我的做法是给每个工具定义重试策略，包括最大重试次数、退避策略、以及失败后的降级方案。
第三层是结果处理。工具返回的结果可能很大，不能直接塞回上下文。要做截断、摘要、或者结构化提取。比如一个搜索工具返回了20条结果，我通常只保留前5条的标题和摘要，其余的在需要时再按需获取。
| 错误类型 | 典型场景 | 处理策略 | 是否重试 |
|---|---|---|---|
| 网络超时 | 外部API响应慢 | 指数退避重试 | 是 |
| 参数格式错误 | 模型输出JSON不合法 | 返回错误让模型修正 | 否 |
| 业务逻辑错误 | 查询条件无结果 | 返回空结果让模型决策 | 否 |
| 权限错误 | 工具未授权 | 上报并终止当前分支 | 否 |
| 限流错误 | 调用频率超限 | 延迟后重试 | 是 |
2.4 状态管理与持久化：让Agent“记得住、断得开”
Agent执行过程中会产生大量状态：当前步骤、已完成步骤、中间结果、工具调用记录、错误信息等等。这些状态如果只存在内存里，进程一重启就全没了，这在生产环境是不可接受的。
状态管理的设计要点有三个：
一是状态的结构化。不要用一个大字典把所有东西塞进去，要按任务、步骤、工具调用分层组织。我通常用类似{task_id: {status, steps: [{step_id, status, input, output, error}]}}的结构，这样查询和更新都很清晰。
二是状态的持久化时机。不是每一步都要写数据库，那样开销太大。我的策略是：关键节点必须持久化（任务创建、步骤完成、工具调用成功/失败），中间状态可以缓存在内存里定期刷盘。这样既保证了可恢复性，又控制了写入频率。
三是状态的清理策略。Agent任务完成后，状态不能一直留着占空间。要设置TTL，过期自动清理。但清理前要确保任务确实结束了，不能把还在执行的任务状态删了。我一般用“最后更新时间+任务状态”双重判断。
3. 工程落地的核心模块与实操要点
3.1 编排引擎：任务图还是状态机
编排引擎是Agent Runtime的大脑，它决定了任务怎么流转、步骤怎么调度。工程上主要有两种实现思路：任务图和状态机。
任务图（DAG）的思路是把任务拆成节点和边，节点是执行单元，边是依赖关系。这种方式的优点是可视化好、并行调度容易，适合步骤之间依赖关系明确的场景。缺点是遇到需要动态调整流程的场景不够灵活，图一旦确定就很难改。
状态机的思路是定义一组状态和转移条件，Agent的执行过程就是状态转移的过程。这种方式的优点是灵活，可以根据运行时条件动态决定下一步。缺点是可预测性差，复杂状态机容易变成“面条代码”。
我的实际选择是混合方案：顶层用任务图做粗粒度编排，每个节点内部用状态机做细粒度控制。这样既有全局的可视化和并行能力，又有局部的灵活性。具体实现上，我用一个Orchestrator组件来管理任务图，每个节点是一个Executor，Executor内部维护自己的状态机。
这里有个关键细节：节点之间的数据传递。不要让节点直接读写全局状态，而是通过明确定义的输入输出契约来传递数据。每个节点声明自己需要什么输入、产出什么输出，Orchestrator负责在节点之间做数据映射。这样做的好处是节点可以独立测试、独立替换，整个系统的耦合度大大降低。
3.2 工具注册与发现：插件化设计的取舍
Agent的能力边界由它可用的工具决定。工具系统的设计直接影响到Agent能做什么、扩展起来方不方便。
我见过两种极端的做法：一种是硬编码，所有工具写死在代码里；另一种是纯动态发现，运行时从某个注册中心拉取工具列表。前者扩展性差，加个工具要改代码重新部署；后者灵活但不可控，工具质量参差不齐。
我的做法是插件化注册+静态审核。工具以插件的形式开发，每个插件声明自己的元信息（名称、描述、参数schema、权限要求），但注册到Runtime时需要经过审核流程。审核包括：schema合法性检查、权限范围确认、以及一个简单的冒烟测试。审核通过后工具才进入可用列表。
工具描述的质量很关键。模型是根据描述来决定用哪个工具的，描述写得含糊，模型就会选错工具。我写工具描述的经验是：说清楚“什么时候用”比“这个工具是什么”更重要。比如一个搜索工具，不要只写“搜索网页”，要写“当需要获取实时信息或验证事实时使用，输入为查询关键词，返回相关网页摘要”。
注意：工具的参数设计要尽量简单。我见过一个工具参数有十几个字段，模型每次调用都要纠结填什么。后来我把参数精简到三个必填项，其余用默认值，调用成功率立刻上去了。模型不是万能的，别让它做太多填空题。
3.3 可观测性建设：Agent的“黑匣子”怎么打开
Agent系统最让人头疼的就是出了问题不知道哪一步错了。传统的日志在Agent场景下不够用，因为Agent的执行是动态的、多轮的，你需要看到完整的决策链路。
可观测性建设要覆盖三个维度：
Trace（链路追踪）：记录一次Agent任务从开始到结束的完整调用链，包括每个步骤的输入输出、工具调用、耗时、状态变化。我用的是OpenTelemetry标准，每个任务一个Trace，每个步骤一个Span，工具调用作为子Span。这样在追踪系统里能直观看到时间花在哪了。
Metrics（指标监控）：关键指标包括任务成功率、平均步骤数、工具调用成功率、上下文token消耗、端到端延迟。这些指标要按任务类型、工具类型、模型类型分组统计，这样才能定位到具体问题。
Logging（日志记录）：详细的调试日志，包括模型的原始输出、参数校验结果、重试记录等。日志要结构化，方便检索。但要注意日志量控制，不能把模型的每次输出都打全量日志，那样存储成本扛不住。
我踩过的一个坑是：早期没做Trace，线上任务失败只能靠翻日志猜。后来加了Trace之后，一眼就能看出是模型决策错了还是工具执行失败了，排查效率提升了一个数量级。
3.4 安全与权限：Agent不能是“裸奔”的
Agent有了工具调用能力之后，安全问题就变得非常现实。一个没有权限控制的Agent，理论上可以调用任何工具做任何事，这在生产环境是不可接受的。
安全设计要覆盖几个层面：
工具级权限：每个工具声明自己需要的权限，Agent只能调用自己被授权的工具。权限粒度要细，比如“读文件”和“写文件”要分开授权。
参数级校验：即使工具被授权了，参数也要校验。比如一个执行命令的工具，要限制命令白名单，防止模型生成危险命令。
操作审计：所有工具调用都要记录审计日志，包括谁调的、调了什么、参数是什么、结果是什么。这不仅是安全需要，也是问题排查的需要。
人工确认机制：对于高风险操作（比如写数据库、发邮件），要支持人工确认。我的做法是在编排层加一个“确认节点”，高风险操作前暂停，等待人工审批后再继续。
4. 完整实操：从零搭一个最小可用Agent Runtime
4.1 环境准备与依赖选型
这一节我带你从零搭一个最小可用的Agent Runtime。不追求功能完整，但求把核心链路跑通，让你理解每个模块怎么协作。
技术选型上，我用Python做示例，因为生态最成熟。核心依赖包括：
- 模型调用：用任意支持function calling的模型API，这里不绑定具体厂商，用抽象接口封装。
- 状态存储：开发阶段用SQLite，生产环境换PostgreSQL或Redis。
- 编排引擎：自己写一个轻量的Orchestrator，不引入重型框架，这样你能看清每个细节。
- 可观测性：用标准logging模块，生产环境接OpenTelemetry。
# 核心数据结构定义 from dataclasses import dataclass, field from enum import Enum from typing import Any, Optional import json import time class StepStatus(Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" FAILED = "failed" @dataclass class ToolCall: tool_name: str arguments: dict result: Optional[Any] = None error: Optional[str] = None retry_count: int = 0 @dataclass class Step: step_id: str description: str status: StepStatus = StepStatus.PENDING tool_calls: list = field(default_factory=list) output: Optional[str] = None error: Optional[str] = None @dataclass class TaskState: task_id: str goal: str steps: list = field(default_factory=list) current_step_index: int = 0 status: str = "running" created_at: float = field(default_factory=time.time) updated_at: float = field(default_factory=time.time)这个数据结构是整个Runtime的基础。TaskState是顶层容器，Step是执行单元，ToolCall记录每次工具调用。注意每个结构都有明确的字段和类型，不要用裸字典，否则后面调试会很痛苦。
4.2 编排引擎的核心实现
编排引擎的核心逻辑是一个循环：取当前步骤、执行、更新状态、判断是否继续。听起来简单，但细节很多。
class Orchestrator: def __init__(self, model_client, tool_registry, state_store): self.model = model_client self.tools = tool_registry self.store = state_store self.max_steps = 20 # 防止无限循环 def run(self, task_id: str, goal: str): state = TaskState(task_id=task_id, goal=goal) self.store.save(state) # 第一步：生成执行计划 plan = self._generate_plan(goal) state.steps = [ Step(step_id=f"s{i}", description=desc) for i, desc in enumerate(plan) ] self.store.save(state) # 逐步执行 while state.current_step_index < len(state.steps): if state.current_step_index >= self.max_steps: state.status = "max_steps_exceeded" break step = state.steps[state.current_step_index] step.status = StepStatus.RUNNING self.store.save(state) try: result = self._execute_step(state, step) step.output = result step.status = StepStatus.SUCCESS state.current_step_index += 1 except Exception as e: step.error = str(e) step.status = StepStatus.FAILED # 失败后尝试重新规划 if not self._replan(state, step): state.status = "failed" break state.updated_at = time.time() self.store.save(state) if state.status == "running": state.status = "completed" self.store.save(state) return state这段代码有几个关键设计点值得说明。max_steps是防止Agent陷入无限循环的硬性保护，我见过太多Agent因为某个步骤反复失败而无限重试，把token烧光。_replan是失败恢复机制，当某一步执行失败时，不是直接终止，而是让模型基于当前状态重新规划剩余步骤。这个机制在实际项目中救过很多次场。
4.3 工具调用的完整链路
工具调用链路包括：模型决策、参数校验、执行、结果处理四个环节。每个环节都要有防护。
class ToolRegistry: def __init__(self): self.tools = {} def register(self, name, func, schema, max_retries=2): self.tools[name] = { "func": func, "schema": schema, "max_retries": max_retries } def validate_args(self, name, args): schema = self.tools[name]["schema"] # 简化的schema校验，生产环境用jsonschema库 required = schema.get("required", []) for field in required: if field not in args: raise ValueError(f"缺少必填参数: {field}") return True def execute(self, name, args): if name not in self.tools: raise ValueError(f"未知工具: {name}") self.validate_args(name, args) tool = self.tools[name] last_error = None for attempt in range(tool["max_retries"] + 1): try: result = tool["func"](**args) return result except TimeoutError as e: last_error = e time.sleep(2 ** attempt) # 指数退避 except Exception as e: # 非超时错误不重试 raise raise last_error参数校验这里我用了简化版，生产环境建议用jsonschema库做完整校验。重试策略上，只有超时错误才重试，其他错误直接抛出。这个区分很重要，因为参数错误重试多少次都是错的，只会浪费时间。
4.4 上下文组装与压缩策略
上下文组装是每次调用模型前都要做的事。核心原则是：只给模型当前步骤需要的信息。
class ContextBuilder: def __init__(self, max_tokens=8000): self.max_tokens = max_tokens def build(self, state, current_step): # 系统提示：角色和能力边界 system = "你是一个任务执行Agent。根据当前步骤描述，决定调用哪个工具。" # 任务上下文：目标 + 已完成步骤摘要 completed = [ f"步骤{s.step_id}: {s.description} -> {s.output[:100]}" for s in state.steps[:state.current_step_index] if s.status == StepStatus.SUCCESS ] task_context = f"总目标: {state.goal}\n已完成:\n" + "\n".join(completed) # 当前步骤 current = f"当前步骤: {current_step.description}" # 可用工具 tools_desc = self._format_tools() # 组装并检查token预算 messages = [ {"role": "system", "content": system}, {"role": "user", "content": f"{task_context}\n\n{current}\n\n可用工具:\n{tools_desc}"} ] return self._truncate_if_needed(messages) def _truncate_if_needed(self, messages): # 简化的token估算，生产环境用tiktoken total = sum(len(m["content"]) for m in messages) if total > self.max_tokens * 4: # 粗略估算 # 压缩已完成步骤的摘要 pass return messages上下文压缩这里有个技巧：已完成步骤的摘要不要保留完整输出，只保留关键结果。比如一个搜索步骤，不需要保留所有搜索结果，只保留“找到了X个相关结果，关键信息是Y”。这样能大幅节省token。
5. 常见问题与排查技巧实录
5.1 Agent陷入死循环怎么办
这是最常见的问题。Agent反复调用同一个工具，或者在不同步骤之间来回跳转，就是完不成任务。
排查思路分三步。第一步看Trace，确认循环发生在哪个环节。是模型反复生成相同的工具调用，还是编排逻辑有问题导致步骤重复执行。第二步看上下文，检查是不是上下文里缺少了“已经做过这一步”的信息，导致模型不知道自己做过了。第三步看工具返回，有时候工具返回了错误信息但模型没理解，就会一直重试。
解决方案上，我通常加三层防护：一是步骤级别的去重，同一个工具用相同参数调用超过两次就拦截；二是全局步数上限，超过就强制终止；三是循环检测，如果连续三步的工具调用模式相同，就触发重新规划。
实操心得：死循环很多时候是因为工具返回的错误信息不够明确。模型看到“执行失败”不知道该怎么调整，就只能重试。把错误信息写具体，比如“参数date格式错误，期望YYYY-MM-DD，实际收到2024/01/01”，模型就能自己修正。
5.2 工具调用参数总是格式不对
模型输出的参数格式不符合schema，这是第二常见的问题。原因通常有两个：一是工具描述里没写清楚参数格式，二是模型能力不够。
解决办法：在工具描述里用示例说明参数格式，比纯文字描述有效得多。比如不要写“date参数是日期”，要写“date参数格式为YYYY-MM-DD，例如2024-01-15”。另外，可以在系统提示里加一句“输出参数前先检查格式是否符合schema要求”，这个小技巧能减少不少格式错误。
如果模型能力确实不够，可以考虑用结构化输出（structured output）功能，让模型直接输出符合schema的JSON，而不是自由文本。现在主流模型API都支持这个能力。
5.3 上下文爆炸导致模型“失忆”
任务步骤多了之后，上下文越来越长，模型开始忽略前面的指令，或者忘记任务目标。这是上下文窗口的物理限制，不是模型的问题。
应对策略我总结了一个优先级：先压缩，再截断，最后拆分。压缩是把历史步骤做摘要，截断是保留最近N步丢弃更早的，拆分是把长任务拆成多个子任务分别执行。实际项目中我通常组合使用：历史步骤做摘要压缩，如果还是超限就只保留最近5步的详细信息和更早步骤的一句话摘要。
5.4 任务成功率上不去的系统性排查
如果整体成功率偏低，不要一个个case去调，要系统性地看指标。我通常按这个顺序排查：
| 排查项 | 检查方法 | 常见问题 |
|---|---|---|
| 计划质量 | 看生成的计划是否合理 | 计划步骤太粗或太细 |
| 工具选择 | 统计工具调用分布 | 模型偏好某个工具 |
| 参数准确率 | 统计参数校验失败率 | 工具描述不清晰 |
| 执行成功率 | 统计工具执行失败率 | 外部依赖不稳定 |
| 上下文充足度 | 检查是否频繁截断 | 上下文预算太小 |
| 模型能力 | 对比不同模型表现 | 模型选型不当 |
这个表我一般会做成监控面板，每周review一次。大部分成功率问题都能从这几个维度定位到。
5.5 生产环境部署的注意事项
开发环境跑通不代表生产能用。生产部署有几个额外的坑：
并发控制：多个Agent任务同时跑，要控制并发数，否则模型API限流、工具资源竞争都会出问题。我一般用信号量控制并发，根据模型API的QPS限制来设置。
超时设置：每个环节都要设超时。模型调用超时、工具执行超时、整个任务超时，三层都要有。超时后要优雅降级，不能直接崩。
资源隔离：不同任务的执行环境要隔离，避免一个任务的问题影响其他任务。至少要做到状态隔离，有条件的话做进程隔离。
灰度发布：Agent逻辑的改动要灰度，先放小流量验证，确认没问题再全量。因为Agent的行为有不确定性，改动的影响面很难静态评估。
6. 进阶方向：让Agent Runtime更“聪明”的几个思路
6.1 自适应编排：根据任务难度动态调整策略
固定编排策略的问题是，简单任务用了复杂流程浪费资源，复杂任务用了简单流程又搞不定。自适应编排的思路是让Runtime根据任务特征动态选择编排策略。
实现上，可以在任务开始时用一个轻量模型做任务难度评估，简单任务走ReAct直连，复杂任务走Plan-Execute。评估维度包括：步骤数量预估、工具调用复杂度、是否需要多轮交互。这个评估本身也消耗资源，所以只对中等以上复杂度的任务做。
6.2 多Agent协作：什么时候需要，怎么组织
单Agent搞不定的任务，可以考虑多Agent协作。但多Agent不是银弹，它引入了通信开销和协调复杂度。我的经验是，只有当任务可以清晰拆分成独立子任务、且子任务之间依赖关系简单时，才值得上多Agent。
组织方式上，常见的有两种：一种是主从模式，一个Orchestrator Agent负责拆解和协调，多个Worker Agent负责执行；另一种是对等模式，多个Agent平等协作，通过共享状态来协调。主从模式更可控，对等模式更灵活但更难调试。我一般优先选主从模式。
6.3 记忆系统：从“金鱼记忆”到“经验积累”
现在的Agent大多是“金鱼记忆”，任务做完就忘。要让Agent越用越聪明，需要给它加记忆系统。
记忆系统分短期和长期。短期记忆就是当前任务的上下文，前面已经讲过。长期记忆是跨任务的，包括：成功案例、失败教训、用户偏好、领域知识。长期记忆的难点在于怎么存、怎么取。存的时候要结构化，不能存原始对话；取的时候要按相关性检索，不能全量加载。
我目前的实践是用向量数据库存任务摘要和关键决策点，每次新任务开始时检索相似历史任务作为参考。效果上，对于重复性高的任务类型，成功率有明显提升。
6.4 评估体系：怎么知道Agent变好了还是变坏了
没有评估体系的Agent优化就是盲人摸象。评估体系要包括：离线评估集、在线指标监控、以及人工抽检。
离线评估集要覆盖典型任务类型和边界情况，每次改动后跑一遍，看成功率有没有下降。在线指标监控前面讲过，重点是任务成功率、平均步骤数、token消耗。人工抽检是补充，定期看一些实际case，发现指标发现不了的问题。
我踩过的一个坑是：只看成功率指标，结果Agent学会了“偷懒”——遇到难的任务就快速失败，成功率反而好看。后来加了“任务完成度”指标，才把这个漏洞补上。
7. 我个人的一些经验体会
做Agent Runtime这一年多，最大的体会是：工程复杂度远超预期，但每一步的投入都有回报。最开始我也觉得Agent不就是prompt engineering吗，后来发现prompt只是冰山一角，水面下是编排、状态、工具、可观测性、安全这一整套体系。
另一个体会是：不要追求一步到位。我见过团队一上来就想做通用Agent平台，结果三个月没跑通一个完整任务。正确的做法是先跑通一个具体场景的最小闭环，然后逐步抽象、逐步扩展。先解决“能用”，再解决“好用”，最后解决“通用”。
还有一个反直觉的经验：限制比自由更重要。给Agent太多工具、太多自由度，它反而容易迷失。明确的能力边界、清晰的工具描述、严格的参数校验，这些约束让Agent表现更稳定。做Agent Runtime，很多时候是在做“减法”而不是“加法”。
最后分享一个我常用的调试技巧：当Agent行为不符合预期时，先把上下文完整打印出来，逐字读一遍。大部分问题都能从上下文里找到原因——要么是信息缺失，要么是信息冗余，要么是指令有歧义。这个笨办法比任何高级调试工具都管用。
