企业官网建设流程全解析

"agent-native"这个热词，我最初是在一次架构评审会上听到的。当时我们团队花三个月做了一个基于大模型的企业知识库问答系统，演示时效果惊艳，可一上生产环境就露馅了：集成的业务系统越多，任务链路越长，问答准确率掉得越快。后来仔细复盘，核心问题不在于模型选得不够强，而在于整个应用架构仍然是把大模型当作一个"问答接口"来用，而不是把"代理"作为系统的头等公民来设计。

这也是"agent-native"最近在AI工程圈被反复讨论的原因。简单说，agent-native不是一种具体的框架或SDK，而是一种架构理念：从需求定义、数据建模、接口设计、状态管理到运维监控，所有环节都围绕"让代理能够自主完成多步骤任务"来展开。这篇文章我会结合自己做过的几个项目，从设计思路、核心组件、落地实操到踩坑记录，系统地拆解一下agent-native到底意味着什么，以及如何把它真正落到自己的项目里。

1. agent-native到底是什么：先说说"AI扣帽子"式的错误做法

1.1 大多数AI应用的通病：把大模型当成问答接口

在聊agent-native之前，我想先描述一个几乎每家公司在AI化初期都会踩的坑。团队拿到大模型API之后，第一反应通常是：在现有系统的前端加一个聊天窗口，用户输入问题，后端把这个问题和历史记录拼在一起发给大模型，返回结果直接渲染到页面上。整个链路看起来流畅，演示效果也不错，领导看了很开心，但一旦真的有人高频使用就会发现问题：用户问"帮我查一下上个月的订单异常"，模型确实能回答出"上个月有3笔异常订单"，但用户还得自己打开订单系统一个一个去处理。

我把这种模式叫"AI扣帽子"——帽子是AI能力，但底下还是那套传统的CRUD架构：数据存在关系型数据库里，业务逻辑写成一个个同步接口，前端通过表单和按钮驱动后端。大模型在这套架构里只是一个"更聪明的搜索引擎"，它不能操作任何系统，不能推进任何流程，唯一做的事情就是把数据库里查到的内容组织成更像人话的答案。

这种模式的问题在于，它把AI定位成了"顾问"而不是"员工"。顾问可以给你建议，但最终干活的人还是你自己。而agent-native要解决的问题恰恰是：让AI从"回答你"变成"替你办"。这个转变不是换个提示词就能实现的，它要求整个系统的设计逻辑都反过来——不是从用户的点击行为出发，而是从代理的自主决策出发。

1.2 代理优先：换一个视角重构系统设计

那么agent-native到底意味着什么？我个人的理解，核心就四个字：代理优先。翻译成设计原则就是，你在设计任何一个模块时，首先要问自己一个问题：当代理需要完成这个任务时，它需要什么样的接口、什么样的数据、什么样的权限？

举一个很直白的例子。传统订单管理系统的接口设计，通常是围绕前端页面的操作来设计的，比如update_order_status(order_id, status)，前端有一个下拉框，用户选中一个状态点击确认，这个接口就把订单状态改了。但在agent-native架构里，这个接口会被重新设计：代理可能需要先查订单详情，再检查库存，再调用物流接口，最后才更新状态。如果每一步都是独立的同步接口，代理就要来回调用六七次，每次调用都有可能出错，而且token消耗也大。

更好的做法是提供一个面向任务的接口，比如process_refund(order_id, reason, amount)，这个接口内部封装了查单、校验、退款、通知的完整链路。对代理来说，它只需要决策"要不要发起退款"以及"退款金额是多少"，剩下的事情交给确定性代码去完成。这就是agent-native和传统架构最本质的区别：传统架构让代码响应人的操作，agent-native让代码响应代理的意图，而接口设计的粒度也从"操作级"变成了"任务级"。

我用一个生活化的类比来帮助理解。传统应用像电话客服，你打过去问问题，客服只能解答，业务流程还是要你自己去柜台、填表格、等审核。agent-native应用像你雇了一个熟悉你们公司流程的助理，你只需要告诉他"把这个客户的退款处理一下"，他会自己判断需要查什么数据、走什么流程、通知哪些人，最后跟你汇报结果。助理不是万能的，但他有一整套工具和权限，能独立把大部分事情办完。

1.3 不是所有应用都适合agent-native

聊到这里必须泼一盆冷水：不是所有应用都值得改成agent-native架构。判断标准其实很简单，就看你的任务是否具备三个特征。第一，任务是否多步骤：如果用户的操作本质上就是"查一个数、填一个表"，那传统表单加一个AI自动填充就好了，没必要上代理。第二，任务是否跨系统：如果这个任务的完成需要协调订单系统、库存系统、物流系统、财务系统等多个后端的配合，代理的自主决策能力就能派上用场。第三，任务是否需要根据中间结果动态调整：有些业务流程是线性的，一二三四步按顺序走完就行，这种场景用工作流引擎编排更合适；只有那些"走到第三步发现条件不满足，需要换个路径继续"的任务，才真正需要代理来动态决策。

我自己见过最典型的失败案例，是有人把内部的工单审批系统改成了agent-native，代理可以自动审批一些低风险工单。听着很美好，但实际跑下来发现，低风险工单的审批规则是明明白白写在制度里的，用确定性代码写一个规则引擎，一分钟能处理几百个，准确率百分百。而代理的决策有延迟、有token成本、偶尔还会抽风，反而把简单事情搞复杂了。所以记住一句话：agent-native不是银弹，它是给"复杂、跨域、动态"的任务准备的架构方案，简单任务用简单工具解决。

2. 为什么这个理念成了AI应用的分水岭

2.1 技术底座已经成熟：工具调用与长上下文的共同作用

agent-native这个理念其实很早就有人提，但过去做不到，因为技术底座不支持。早几年的对话式AI基本就是"聊天机器人"，模型只能理解和生成文本，没有能力去调用外部系统。真正让agent-native变成现实的技术拐点，是模型开始支持函数调用（Function Calling），以及上下文窗口从几K扩展到了几十K甚至上百K。

函数调用能力的意义，我怎么说都不为过。它让模型不止能"说"，还能"做"——模型在生成回复的同时，可以输出一个结构化的调用请求，比如get_order_detail(order_id="12345")，系统收到这个请求后执行真正的代码，把结果返回给模型，模型再根据结果决定下一步。这个"感知-决策-行动"的循环，就是代理的基本工作模式。没有函数调用能力之前，你只能靠模型输出一段文本来解析，脆弱得让人崩溃；有了函数调用之后，工具的调用变得规范化、可解析、可重试，这是agent-native能落地的基石。

另外，长上下文窗口也给代理带来了一个重要能力：它可以在一次会话中携带更多的中间结果。以前模型翻几轮对话就忘记前面的信息了，你让它执行一个五步任务，走到第三步它已经把第一步的结果丢了。现在配合良好的上下文管理，代理至少能"记住"整个任务执行过程中的关键信息，这是多步骤自主完成任务的一个基本前提。

2.2 从"端到端问答"到"端到端任务闭环"

如果说过去的AI应用追求的是"端到端问答"——用户问一句，模型答一句，那么agent-native追求的是"端到端任务闭环"——用户提出一个目标，代理规划、执行、验证、汇报，直到目标达成。

我用客服场景给你们对比一下。传统AI客服，用户说"我想退款"，模型回答"请提供订单号，我帮您查询退款政策"，用户提供订单号后，模型又说"根据政策您可以退款，请您点击链接自助申请"。每一步都有信息损耗，用户烦，企业也烦——因为AI只负责说话，不负责办事，事情最终还是回到人工流程。而agent-native的客服代理，用户说"我想退款"，代理自己调用订单查询工具找到用户的订单，判断退款条件是否满足，然后调用退款发起工具提交流程，最后再调用通知工具给用户发一条消息："您的订单12345退款已发起，预计3个工作日到账。"

这两种模式的服务质量是完全不同的。前者只是把FAQ变成了对话框，后者是真正把一个业务环节的完整工作交给了AI去闭环。而这种闭环的实现，依赖于代理能够自主地选择工具、执行工具、验证结果，这正是agent-native架构的核心能力。

2.3 三种落地形态：单代理、多代理、人机协同

在实际项目中，agent-native并不是只有一种形态。我把它总结为三种常见的落地架构，每种都有自己的适用场景。

第一种是单代理加工具集，也是目前最简单、最稳妥的形态。一个代理配上十几个工具，围绕某一类任务自主完成。它的优势是逻辑简单、易调试，适合任务边界清晰、专业领域集中的场景。第二种是多代理协作，不同代理负责不同角色，比如一个代理负责信息收集，一个代理负责方案生成，一个代理负责质量审核，它们之间通过消息传递协调整体任务。这种形态适合复杂任务，但调试难度成倍上升，因为你需要同时追踪多条对话链路的执行情况。第三种是人机协同，代理自主执行的同时，在关键节点上把决策权交给人类，比如涉及高金额退款、敏感数据访问时，代理会暂停并请求人工确认。这种形态在实际生产环境中最常见，因为很多业务不允许全自动，需要保留人的审批节点。

我个人建议，如果你刚开始做agent-native项目，不要一上来就搞多代理架构。先做单代理，跑通闭环，再根据业务复杂度逐步演进。多代理带来的分布式调试地狱，真的会让人怀疑人生。

3. agent-native应用的核心组件：状态、工具、上下文、安全四件套

3.1 状态与记忆层：代理不能"失忆"

agent-native应用的第一个核心组件是状态管理。一个代理在跑一个多步骤任务的时候，需要持续跟踪当前进展：这个订单已经查过了，退款条件已经确认，下一步要发通知。如果每一步都是无状态的接口调用，代理每走一步都要重新查一遍前面的信息，效率和可靠性都无从谈起。

我在实际项目中一般把状态分成三层。第一层是会话状态，保存在内存或Redis里，记录了当前任务执行到哪一步、拿到了哪些中间结果，生命周期通常是几分钟到几小时。第二层是业务状态，保存在数据库里，记录代理发起了哪些业务操作、是否成功、产生了什么业务单据，这是要长期留痕的数据。第三层是长期记忆，通常用向量数据库来存，记录代理在历史任务中学到的用户偏好、业务规则、历史决策，用于后续任务的参考。

这里必须强调一个原则：单一事实来源。代理执行过程中产生的所有关键信息，必须最终落到持久化存储中，而不是只存在于对话上下文中。原因很简单，对话上下文是易失的，会话一断信息就没了，而且上下文里可能会有模型幻觉产生的错误信息，不能作为业务数据的依据。我见过一个项目，代理把订单号临时放在上下文里，会话一断，后续流程全部找不到订单——这属于非常低级的架构错误。

3.2 工具协议层：代理的"手"

工具层是agent-native应用里代理做事的"手"，也是最容易设计失误的部分。工具的本质是把系统能力暴露给代理，而代理是通过工具的Schema描述来理解怎么用它的。所以工具描述的质量，直接决定了代理使用工具的成功率。

以我常用的订单查询工具为例，它的Schema描述长这样：

{ "type": "function", "function": { "name": "query_order", "description": "根据订单号或用户ID查询订单详细信息，包含商品列表、金额、状态、物流单号。适合在用户咨询订单状态、申请退款或催发货时使用。", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单编号，形如 ORD20240115001" }, "user_id": { "type": "string", "description": "用户唯一标识，形如 U10001" } }, "required": ["order_id"] } } }

注意几个细节。第一，description不能只写"查询订单"，要写清楚这个工具在什么场景下使用，代理才会在合适的时候选择它。我见过太多人把工具描述写得极其简陋，结果代理遇到问题根本不知道该调用哪个工具。第二，参数要加上格式示例，比如ORD20240115001，这能显著降低模型生成非法参数的概率。第三，不要给一个工具塞太多功能，比如"查询订单并同时修改订单状态"，这种混合功能的工具会让代理的决策变得混乱，也很容易造成误操作。

工具注册表的设计也有讲究。我建议在系统启动时统一注册所有工具，并维护一份工具列表，方便统一更新和审计。代理每调用一次工具，都要记录调用时间、输入参数、返回结果和耗时，这些日志在日后排查问题时至关重要。

3.3 上下文工程层：别把整个历史都塞给模型

第三个核心组件是上下文管理。很多人的第一直觉是把对话的历史消息全部传给模型，这样最省事。但实际跑下来你会发现，上下文越长，token成本越高，模型的响应延迟越长，而且更糟糕的是，无关信息越多，模型越容易做出错误的决策。这就是所谓的"上下文污染"。

我在项目中采用的是一套分层的上下文管理策略。核心思路是：不要把所有消息都塞进去，而是只塞当前任务真正需要的部分。具体来说，系统会在每次代理循环开始前，做几个动作。第一，把历史对话做一次摘要，把"用户之前说过什么、做过什么决定"压缩成一段简短的状态描述。第二，把最近几轮的工具调用结果做一次筛选，只保留当前决策直接相关的关键信息，比如订单号、金额、状态这些。第三，如果任务涉及检索外部知识，检索到的长文档不会直接全量塞进上下文，而是先检索再截断，只提取与当前问题最相关的那几段。

这套策略听起来简单，但实现起来需要一个良好的消息组装模块。我会在第四节展示具体的代码框架。总之记住一句话：上下文工程的本质不是"尽可能多地给模型信息"，而是"给模型当前决策最需要的那一小撮信息"。做得好，效果立竿见影，token成本可能直接降一半。

3.4 安全与边界：尽早给代理上锁

最后是安全层，这也是很多团队容易忽视的。我见过一个项目，代理被授予了数据库的全部增删改查权限，结果有一次模型幻觉，调用了删除接口，把一批测试数据清空了。这个教训非常深刻。agent-native架构里，代理拥有自主调用工具的能力，这本身就意味着风险，所以权限控制和审计机制必须从一开始就设计好。

我的做法是给每个代理分配一把"最小权限钥匙"。核心原则包括几条。第一，按角色授权：负责查询的代理只能访问只读工具，负责执行的代理可以访问写操作工具，但写操作必须经过二次确认。第二，高危操作必须人工审批：涉及资金、删除、修改敏感数据、对外发送消息的操作，代理会生成一个"待确认操作"挂在工单里，由人来点确认才真正执行。第三，所有工具调用全程留痕：每一次调用都要记录操作人（或代理ID）、时间、入参、出参、结果，形成完整的审计链路。安全设计不是上线前临时加的，而应该在架构设计的第一天就做进去，否则后面想补会非常痛苦。

4. 实操：一个客户订单处理助手的agent-native落地全过程

4.1 需求定义与边界划分

理论聊了这么多，还是得落到代码上。我拿一个真实的项目例子来讲：做一个客户订单处理助手。任务边界定义得很清楚：帮助客服人员处理用户的订单查询、退款申请和发货催办，不涉及商品上架、价格修改等高风险操作。

我先列出代理需要的能力，也就是工具清单。查询订单详情，这是最基础的工具。查询用户信息，用来识别用户身份和联系偏好。发起退款申请，这个属于高权限操作，需要二次确认。发送通知消息，告诉用户退款进展或物流信息。查询物流状态，用于回应用户关于"我的快递到哪了"的问题。

权限划分上，查询类工具全部开放给代理自主调用；退款申请和发送通知这两个写操作，代理可以发起，但系统会生成待确认任务，由人工在管理后台点确认后才真正执行。这个边界设定非常关键，既保证了效率，又守住了安全的底线。

4.2 代码骨架：工具注册器与代理循环

接下来是核心代码骨架。我用Python写一个简化的实现，不绑定任何特定的大模型SDK，方便大家理解核心逻辑。首先是一个工具注册器：

# tool_registry.py import inspect import json from typing import Any, Callable, Dict, Optional class ToolRegistry: """统一的工具注册器，负责注册、描述和调用工具。""" def __init__(self): self._tools: Dict[str, Dict[str, Any]] = {} def register( self, func: Callable, name: Optional[str] = None, description: Optional[str] = None, parameters: Optional[Dict] = None, ): """注册一个工具，显式传入name、description和parameters Schema。""" tool_name = name or func.__name__ self._tools[tool_name] = { "func": func, "meta": { "type": "function", "function": { "name": tool_name, "description": description or func.__doc__ or "", "parameters": parameters or {}, }, }, } def get_schemas(self) -> list: """返回所有工具的JSON Schema，用于传给模型。""" return [tool["meta"] for tool in self._tools.values()] def call(self, name: str, arguments: Dict) -> Any: """调用指定工具，校验参数并统一捕获异常。""" tool = self._tools[name] try: return tool["func"](**arguments) except Exception as e: return json.dumps({"error": str(e), "success": False}) # 全局注册器 registry = ToolRegistry()

然后定义两个实际工具：

# tools.py import json from tool_registry import registry # 模拟数据库 ORDERS_DB = { "ORD20240115001": {"order_id": "ORD20240115001", "user_id": "U10001", "amount": 299.00, "status": "shipped", "items": ["蓝牙耳机"]}, "ORD20240201002": {"order_id": "ORD20240201002", "user_id": "U10002", "amount": 1299.00, "status": "pending_refund", "items": ["机械键盘"]}, } @registry.register( name="query_order", description="根据订单号查询订单详细信息，包含商品、金额、状态。适合在用户咨询订单状态或申请退款时使用。", parameters={ "type": "object", "properties": { "order_id": { "type": "string", "description": "订单编号，形如 ORD20240115001", } }, "required": ["order_id"], }, ) def query_order(order_id: str): order = ORDERS_DB.get(order_id) if not order: return json.dumps({"success": False, "message": "订单不存在"}) return json.dumps({"success": True, "data": order}) @registry.register( name="request_refund", description="为用户订单发起退款申请。该操作为高风险操作，必须返回待审批状态。", parameters={ "type": "object", "properties": { "order_id": {"type": "string"}, "reason": {"type": "string"}, }, "required": ["order_id", "reason"], }, ) def request_refund(order_id: str, reason: str): # 实际项目中这里应该调用工单系统创建待审批工单 return json.dumps({ "success": True, "message": "退款申请已提交，等待人工审批", "data": {"order_id": order_id, "reason": reason, "status": "pending_approval"}, })

最后是代理的循环主体：

# agent.py import json from tool_registry import registry SYSTEM_PROMPT = """你是一个客户订单处理助手。 你的任务是根据用户的诉求，调用合适的工具完成查询和处理。 对于退款等敏感操作，只需调用工具发起申请，不需要你自己确认结果。 如果工具返回错误信息，请你根据错误内容调整策略后重试，或者如实告知用户无法处理。""" def run_agent(user_input: str, max_iterations: int = 6): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input}, ] for step in range(max_iterations): # 调用大模型接口，这里用伪代码示意 response = llm_client.chat( messages=messages, tools=registry.get_schemas(), temperature=0.2, ) # 如果模型要求调用工具 if response.finish_reason == "tool_calls": messages.append({"role": "assistant", "content": response.content, "tool_calls": response.tool_calls}) for tool_call in response.tool_calls: tool_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) tool_result = registry.call(tool_name, arguments) # 把工具结果作为新消息回传给模型 messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": tool_result, }) continue # 进入下一轮循环，让模型基于工具结果继续决策 # 如果模型直接返回文本，说明任务结束 return response.content # 超出最大迭代次数，强制结束 raise RuntimeError(f"Agent reached max_iterations={max_iterations}, stopping.")

这个骨架已经能跑通一个基本的agent-native应用了。用户说"我想退掉订单ORD20240201002"，代理会先调用query_order查出订单信息，再调用request_refund发起退款申请，最后给用户一个总结。整个过程中，代理的每一步决策都是自主完成的，这就是agent-native的基本运行模式。

4.3 关键参数与策略选型

代码骨架之外，有几个关键参数和策略我在实际项目中反复调过，分享给大家作为参考。

第一个是max_iterations。我见过很多人把这个值设成20、30，觉得"多给代理几轮机会总没错"。但实际经验是，迭代次数越多，token消耗越大，出错率也越高。一个正常的任务，三步到五步就能完成；如果一个任务跑了十几步还没结束，大概率是代理陷入了死循环或者决策混乱，这时候继续给它机会只会浪费钱。我建议生产环境默认设6，上限10，超过就自动熔断，把任务转给人工处理。

第二个是温度参数。工具的调用是一种"确定性决策"，不是"创造性写作"，所以温度一定要低。我一般设0.1到0.3之间，确保代理选择工具和生成参数时尽量稳定。如果温度太高，同样的输入可能每次给出不同的工具调用，这是不可接受的。

第三个是重试策略。工具调用失败太常见了，比如参数格式非法、数据库超时、订单不存在等等。我的做法是给工具调用结果中带上明确的错误信息，让模型看到错误后自己决定"换一种参数重试"还是"放弃并告知用户"。但要注意，重试也要有上限，同一个工具连续失败三次就直接放弃，防止代理在同一个错误上反复打转。

第四个是模型分级。在真实的agent-native系统里，我不会所有任务都用最强的大模型。简单查询、标准化回复可以用便宜的小模型，复杂决策任务才用强模型。这个"混合模型路由"策略能大幅降低整体成本，尤其是在代理循环中每一步都要调用模型的场景下。

4.4 从Demo到生产还要补的工程细节

演示代码只是一个骨架，真正上生产之前还得补几个工程细节。首先是要解决幂等性，工具调用必须支持重试且不产生副作用，比如request_refund如果因为网络问题超时，重试时不能重复创建两个退款工单，我的做法是在工具里做幂等校验，同一个order_id在相同业务场景下只能创建一次。其次是超时与降级，如果大模型API调用超时，代理要快速失败并且把任务转给人工队列，而不是让用户无限等待。第三是可观测性，代理的每一轮思考、每一个工具调用、每一次决策变更都要有日志和链路追踪，否则生产环境出了问题你根本无从下手定位。这些细节虽然不性感，但它们恰恰是agent-native应用能否稳定运行的关键。

5. 常见问题与排查技巧实录

5.1 工具调用陷入死循环

第一个高频问题，是代理在工具调用中陷入死循环。现象很典型：代理反复调用同一个工具，或者在一两个工具之间来回切换，就是不返回最终结果。比如用户问"我的订单什么时候到"，代理可能反复调用query_order和query_logistics，每轮都拿到相同的信息，但就是不结束对话。

排查思路有几个方向。第一，检查工具返回的信息是否有冗余，如果工具每次都返回一堆无关字段，模型会把那些无关字段误判为需要进一步处理的信息。第二，检查系统提示词里有没有给出"结束条件"，我经常会加一句"如果你已经拿到了用户需要的答案，请直接回复，不要再调用工具"。第三，检查是否缺少失败的熔断机制，我上面提到的max_iterations就是一个安全网，但更重要的是在代码里检测"重复调用同一个工具且参数相同"的情况，一旦检测到就强制终止，然后转人工。

5.2 上下文污染导致决策混乱

另一个非常常见的问题是上下文污染。最典型的表现是：代理在第一轮调用了一个查询工具，返回了错误信息（比如"订单不存在"），后面所有决策都受到这个错误信息的影响，即使后续用户补充了正确的订单号，代理还是一直围绕着"订单不存在"打转。这就是典型的"历史错误信息污染了当前决策"。

我解决的思路是给上下文做"换血"和"净化"。当检测到关键信息发生改变时（比如用户重新提供了订单号），我会主动把之前的错误状态从消息历史中压缩掉，只保留"用户重新提供了订单号"这个事实，而不再保留"之前查不到订单"的历史错误。此外，工具返回的大段结果不会全部进上下文，我会先做一个字段筛选，只取出当前决策真正需要的那几个字段，比如订单状态和金额，其他全部丢弃。做过这个优化之后，代理的决策准确率提升非常明显。

5.3 状态不一致与并发冲突

第三个问题是状态一致性和并发冲突。当多个用户同时发起任务时，如果代理的状态是全局共用的，就会出现A任务的状态覆盖了B任务的问题。我在一个早期项目中踩过这个坑：两个客服同时在系统里处理退款，由于共享了一个"当前订单"的状态变量，代理A查的订单信息被代理B覆盖了，结果A的退款申请提交了错误的订单号。

解决方案非常直接：每个任务实例必须拥有独立的状态上下文，所有中间变量都按任务ID隔离。同时，涉及数据库写入操作时要用事务和乐观锁，防止两个代理同时对同一张订单做操作。这其实和常规的后端并发控制没有本质区别，只是很多人做AI应用时觉得"模型很智能"，就把老一套的并发控制抛在脑后了。

5.4 成本失控：一个简单任务烧掉上千个Token

最后一个问题是成本。agent-native的代理循环天然是token消耗大户，因为每一轮决策都要调用一次模型，每调用一次工具都要把工具结果塞回上下文。如果设计不当，一个简单任务的token成本可能比传统问答高十倍。

成本控制的核心是"少调、短传"。少调是指减少不必要的模型调用次数，把通用逻辑的决策留给确定性代码；短传是把工具结果和上下文尽量压缩，能传摘要就不传全文。我还有一个非常实用的习惯：每次代理循环结束，都在日志里记录"本轮消耗的token数"和"累计消耗token数"。刚开始做这个监控的时候，你可能会被数字吓一跳，但这恰恰是优化的第一步。控制在合理范围内之后，agent-native应用的运行成本完全可以接受，尤其当你用混合模型路由把简单调用分流到便宜模型之后，整体成本会进一步下降。

最后分享一点个人体会。agent-native真正难的不是"跑通一个demo"，而是"守住系统的确定性"。模型天生不确定，但工程架构可以给它划定一个相对确定的边界——工具协议是确定的，状态流转是确定的，权限边界是确定的，失败处理是确定的。把这个边界搭好，模型的能力才真正变得可用。这也是我这两年做过的所有AI项目最核心的一条经验。如果你正在准备上一个agent-native项目，建议先别急着写代码，花两天时间把工具边界、状态模型和权限清单画清楚，后面的路会顺畅很多。