Agent商业生态与技术全景

从一个每天用Agent的软件工程师的视角谈谈对Agent生态和技术理解
合作者: Claude帮我理解知识、写草稿, DeepSeek校对、微调博客
对话轮数：56 turns

Agent商业生态分层

围绕agent做生意的公司可大致分三层。越往下越底层、越通用；越往上越贴近具体客户和场景。

基础设施层：算力、芯片、云端GPU租赁。竞争维度是成本和供应能力，与具体的agent应用形态无关。两个典型角色：

• 芯片厂商（英伟达、AMD）：卖物理算力，拼制程和产能
• 云厂商（AWS、GCP、Azure）：拼资源整合效率和服务生态，把算力包装成可租赁的云服务，附加存储、网络、托管推理等配套

对应软件岗位是Infra工程师，分布式调度、GPU资源管理、沙箱隔离、推理服务托管。

模型层：LLM厂商，出售的是agent赖以决策的推理能力。竞争维度包括推理成本、速度、上下文窗口、推理能力、多模态支持。护城河是训练成本与数据/算法积累。分两类：

• 通用模型厂商（OpenAI、Anthropic、DeepSeek）：卖横向推理能力，追求通用性
• 垂类模型厂商：在特定领域做深度优化，比如代码模型、法律模型、金融模型

对应软件岗位是算法工程师，数据清理、模型设计、train/eval、预训练微调、推理性能优化。垂类公司一般局限于数据清理、微调和推理。

应用层：将模型封装为实际可用的agent产品或系统。分两类：

• 通用产品型（Claude Code、Codex、CoWork）：agent本身就是产品，直接卖给终端用户
• 垂类公司型：在内部搭建agent系统嵌入已有产品线。核心优势是过去积累的私有数据、用户体验护城河，agent赋能提升用户粘性

对应软件岗位是AI工程师，工具编排、循环控制、上下文管理。交付侧还有FDE，Forward Deployed Engineer，签单后进场，将产品代码写入客户仓库、对接私有数据系统，长期负责生产运行。

垂类公司用agent构建竞争力的路径：

1. 提升操作体验：agent代劳原本需要人工的重复操作
2. 内部运营降本：客服、审批流程agent化；将资深员工的隐性经验产品化，沉淀为可复用的系统能力，防止随人员流失消失
3. 激活数据资产：沉睡数据变为可检索、可分析的洞察，用于迭代产品

一家公司通常同时沿多条路径推进。

Agent Engineering技术全景

LLM本身只会生成文字。它没有网络接口，没有文件系统权限，不能执行任何动作。 所有真正"动手"的工作，发请求、跑代码、读文件，都要靠包裹在LLM外面的工程系统来完成。

Agent Engineering分为三大块：

• Harness Engineering：控制流。管LLM能调用哪些工具、怎么编排、什么时候停。
• Context Engineering：数据流。管每一轮往上下文里放什么、放多少、什么顺序。
• 迭代改进闭环：时间维度。管系统怎么随时间变得更好，不参与单次任务执行。

Harness执行时依赖Context提供的内容，迭代改进闭环通过观测Harness的执行记录来决定怎么优化前两者。

Harness：骨架与控制流

Loop Engineering

设计"LLM决定调用工具→harness执行→结果回传LLM→LLM再判断"这一循环本身。具体机制：

• 终止判断：解析API返回字段，区分工具调用与最终答案
• 硬性熔断：最大循环次数和token预算上限
• 卡死检测：连续多轮调用相同工具和参数即判定原地打转
• 失败重试：通常用指数退避
• Human-in-the-loop：高危操作（发邮件、转账、删文件）硬编码强制暂停等确认；普通模糊问题允许LLM自主决定是否反问

难点不在单个机制，而在机制互相冲突时的权衡：摘要压缩历史对话省token但可能丢关键数据，并行调用提速但引入竞态问题。

相关项目：LangGraph的create_react_agent封装了完整的loop机制，包括终止判断、熔断和重试策略，是Loop Engineering的典型参考实现。

Workflow

与Loop Engineering的动态决策不同，Workflow是预定义的确定性执行路径。步骤顺序、分支条件在代码或配置中显式声明，不依赖LLM动态决策。适合步骤固定、边界清晰的场景，比如数据管道式的agent任务。

实践中常与动态循环混合使用：整体流程用workflow固定骨架，步骤内部放开让LLM自主决定。

相关项目：LangGraph的StateGraph用图结构显式声明节点和边，天然支持workflow；n8n是低代码workflow编排工具，适合非技术团队搭建固定流程的agent系统。

路由

工具路由决定当前轮调用哪个工具。主流做法是LLM语义路由：system prompt中放工具目录，LLM自行判断。工具多或语义重叠时，先用embedding粗筛候选再交LLM最终选择。

模型路由是混用不同档位模型，在成本和效果之间权衡。

相关项目：OpenRouter提供统一的模型路由网关，按token价格和延迟自动选择模型，是模型路由的典型产品化实现。

Multi-Agent Orchestration

从单循环变为循环套循环。最常见的是Orchestrator-Worker（星形）：一个协调者分发任务给多个worker，worker之间不直接通信。复杂度提升后升级为Hierarchical（分层）：顶层战略、中层领域拆分、底层执行。

工具间依赖由LLM显式声明，无依赖标注的可并行；简单系统用"一轮只做一件事"的串行小步循环规避问题。循环依赖的解法偏架构规避：强制通信经过中心协调者，配合超时兜底。

拆分多agent的收益：上下文隔离、权限隔离、并行执行、prompt更聚焦、局部失败不拖累整体。代价是协调开销和信息压缩中的细节丢失。

相关项目：微软的AutoGen和CrewAI都是多agent编排框架，提供Orchestrator-Worker模式的开箱即用实现。

Context Engineering：内容与数据流

Context Engineering回答一个核心问题：每一轮调用，LLM的上下文窗口里应该装什么？ 窗口有限，装什么、不装什么、按什么顺序装，直接决定agent的表现。

窗口内的内容分两类：静态配置和动态注入。

静态配置

静态配置是每次调用都常驻在上下文里的内容。但它内部并非一个整体，按设计目标分为两个独立的部分：

Prompt Engineering行为约束

在agent时代，Prompt Engineering的实际工作已经演变为System Prompt Design，设计的不再是一次提问，而是agent的持久化行为配置。它管的是模型怎么想、怎么说、怎么做判断，核心包含：

• Identity：这个agent是谁、服务谁、能做什么、不能做什么、超出边界时怎么处理
• Behavior：怎么生成输出、遵循什么规则、保持什么风格、优先级原则
• 任务指令与few-shot：当前任务的目标描述、上下文状态，以及行为模式的样例演示

传统的话术技巧被吸收进了这些维度里，不再是独立话题。评价标准是行为质量：格式对不对、角色有没有偏离、推理路径对不对。

相关项目：Anthropic官方的system-prompt仓库公开了Claude系列模型的system prompt设计，是研究agent identity和behavior定义的一手资料。

Harness路由配置

工具目录、工具description、skill名字和一句话描述，这些也是静态注入的内容，但设计目标完全不同：它们管的是模型该调用什么、该加载什么，不管模型怎么输出。

评价标准是路由准确率：该调A的时候有没有调B，该加载skill的时候有没有加载。优化思路和Prompt Engineering不同——这里追求的是描述的精確性和区分度，而不是行为约束的清晰度。

动态注入

每次调用时根据当前任务实时决定塞入的内容，三种主要机制：

• RAG：先检索外部真实数据，再让LLM基于真实材料生成，而非依赖训练记忆中可能过时或编造的内容。背后的原则是Grounding，分析之前先确保数据真实可验证
• Memory：跨会话的长期记忆。两种存储方式：文件系统+目录索引，先给目录摘要，模型判断读哪个文件，可控可解释；向量检索式，历史切片存向量库，靠embedding相似度检索，覆盖面广但质量不稳定
• Skill：渐进式披露的实现。平时只有skill名字和一句话描述常驻system prompt，被路由命中后才注入完整原文

RAG的典型基础设施是向量数据库：ChromaDB轻量嵌入式，适合原型开发；Pinecone托管服务，适合生产环境；Qdrant开源高性能，适合自部署。

Memory层值得关注的项目是MemGPT：把LLM的上下文窗口当作操作系统内存来管理，自动在窗口和外部存储之间做分页，是Memory机制的产品化探索。

Skill机制的代表实现是Claude Agent Skills：Anthropic官方发布的skill规范，目录结构加SKILL.md元数据文件，支持渐进式披露，已被多个开源agent框架采用。

通用考量

无论静态还是动态内容，都要考虑：窗口预算分配；位置效应，首部和尾部注意力更高，中部易被忽视，即lost in the middle；结构化格式，XML或markdown比纯文本更利于LLM遵循规则；相关性过滤与信息新鲜度。

具体案例：Vibe-Trading量化交易agent的macro-analysis skill，内容是一份静态宏观分析框架，包括CPI、PMI阈值表、美林时钟规则、输出模板。文件本身不含数据，真实数据通过工具调用单独获取。静态框架和动态数据作为两个独立信息源同时喂给LLM，harness不做模板替换，将两者关联并得出判断的是LLM的推理能力。规则和数据分开注入，关联判断留给模型。Plan→Ground→Execute→Validate→Deliver这类固定流程同理，写在skill文件中靠LLM遵循，而非代码强制。

Harness与Finetune的边界

Harness改变的是LLM在单次调用中看到什么信息，不能让它学会本来不具备的行为模式；微调改变的是模型权重，让默认行为永久变化。

判断标准不是"知识能否写成文字"，而是两点：

1. 维护成本是否现实：几万条规则人工维护不现实
2. 是否需要泛化到新场景：人工规则只能覆盖写过的case，训练后的模型能对相似新情况合理推断

答案明确写在文档里的知识适合RAG；需要从大量案例中提炼统计规律的，如欺诈识别直觉，只能靠训练。

迭代改进闭环

这一块管系统如何随时间变好，不参与实时单次任务执行。三个环节

Observability：记录agent每步做了什么、调用了哪些工具、消耗多少token。debug和成本追踪的基础。Langfuse是agent可观测性领域最活跃的开源项目，提供trace、token统计、成本追踪、手动标注等完整功能；LangSmith是LangChain官方的同类产品。

Evaluation：无公开benchmark的私有场景下自建考卷：收集典型任务加人工标注作为golden dataset；用独立的评估模型按评分标准打分LLM-as-judge，关键是与被测模型隔离，避免自我评估偏差；定期人工抽查校准。Agent专属评测维度：任务完成率、步骤效率、工具调用准确率、循环熔断触发率。

Fine-tune：很多系统靠改prompt、换模型、优化RAG就能持续改进，不需要走到fine-tune。需要时注意区分两种不同性质的工作：Agent Engineer日常接触的微调是调用厂商API，做数据工程；算法工程师做的是从零训练或做基于预训练模型的大规模微调，碰的是模型架构、学习率、分布式训练这些引擎内部细节。

小结

• LLM负责决策
• Harness负责执行和控制流
• Context Engineering负责决定喂给LLM什么信息
• 迭代闭环负责让系统随时间变聪明

自顶向下理解一个具体agent项目或agent行业各类岗位的实际工作，套用这个框架或许可以理清。