1. 项目概述为什么我们需要一个“信使”智能体最近在折腾AI应用落地的朋友估计都绕不开一个核心痛点如何让大语言模型LLM不只是个“聊天高手”更能成为一个能真正“动手做事”的智能体Agent我们常常遇到这样的场景你问模型“帮我分析一下上个月的销售数据”它能给你一套漂亮的分析框架但真要它去数据库里把数据拉出来、跑个Python脚本、生成可视化图表最后把报告发到你的邮箱它就“哑火”了。这中间的鸿沟就是“思考”与“行动”的差距。Hermes Agent这个项目就是为了填平这道鸿沟而生的。你可以把它理解为一个高度可定制、模块化的“AI信使”框架。它不生产“思考”它只是“思考”的搬运工和执行官。其核心设计哲学是将复杂的智能体任务拆解为清晰、可插拔的模块让开发者能像搭积木一样快速构建出能调用工具、处理多轮对话、管理记忆并执行复杂工作流的智能应用。我花了相当一段时间深入研究和实践Hermes Agent从最初的“跑通Demo”到后来的“定制化深度改造”踩了不少坑也积累了不少心得。今天这篇文章我就来为你彻底拆解这个框架围绕其4大核心模块和3种开箱即用的配置方案分享一套从零到一的实战指南。无论你是想快速搭建一个能联网查资料的问答机器人还是想构建一个能自动化处理日常任务的私人助理这篇文章里的内容都能让你直接“抄作业”。建议收藏因为接下来全是硬核干货和实操中才能获得的经验。2. 核心模块深度拆解Hermes Agent 的四大支柱一个健壮的智能体框架其架构设计决定了它的能力上限和易用性。Hermes Agent 没有追求大而全而是通过四个职责分明的核心模块实现了灵活与强大的平衡。理解这四大模块是你玩转它的第一步。2.1 模块一Orchestrator编排器—— 智能体的大脑与决策中心这是整个智能体的“总司令”。它的核心职责是理解用户意图、规划执行步骤、并协调其他所有模块工作。当你对智能体说“查一下北京明天天气然后告诉我该穿什么衣服”时Orchestrator 的工作流是这样的意图理解与任务分解首先它会分析你的指令识别出两个子任务“查询天气”和“穿衣建议”。工具匹配与调用决策接着它在注册的工具库中寻找匹配的工具。对于“查询天气”它可能匹配到一个get_weather工具对于“穿衣建议”它可能发现没有直接工具但意识到这需要基于第一个任务的结果进行推理。执行规划与流程控制然后它制定执行计划先调用get_weather(北京)获取结果后将结果连同“穿衣建议”的请求再次提交给LLM进行推理生成。异常处理与循环控制如果工具调用失败或者LLM返回的结果不满足要求Orchestrator 负责决定是重试、更换工具还是向用户请求澄清。实操心得Orchestrator 的“思维链”配置是关键。在Hermes中Orchestrator 的能力很大程度上取决于你喂给它的“系统提示词”System Prompt和少样本示例Few-shot Examples。一个常见的误区是只写一句“你是一个有帮助的助手”。对于智能体你需要明确它的角色、可用工具列表、工具调用格式、以及处理多步骤任务的逻辑。注意编写Orchestrator的提示词时一定要用结构化、机器易于解析的格式如JSON来定义工具调用和输出的规范。这能极大提高后续模块解析的准确性和稳定性。我通常会用一个清晰的“任务-工具-输出”模板作为少样本示例。2.2 模块二Tools工具集—— 智能体的手与脚Tools 模块定义了智能体能与外部世界交互的具体能力。这是智能体从“纸上谈兵”变为“实干家”的核心。Hermes Agent 的工具系统设计得非常开放支持同步/异步调用并内置了丰富的常见工具。工具类型概览工具类别典型示例作用关键配置参数网络交互WebSearchTool,APICallTool获取实时信息调用外部APIAPI密钥、请求超时、重试策略数据操作PythonREPLTool,SQLQueryTool执行代码查询或处理数据沙箱环境、数据库连接池、安全限制文件处理ReadFileTool,WriteFileTool读写本地或云存储文件文件路径白名单、权限控制应用控制SendEmailTool,UIAutomationTool发送邮件、模拟用户操作SMTP配置、应用选择器工具定义与注册详解定义一个工具不仅仅是写一个函数。在Hermes中你需要为工具提供完整的“元数据”以便Orchestrator能准确理解和调用它。# 一个简单的自定义工具示例获取股票价格 from hermes.agent.tools import BaseTool from pydantic import Field class GetStockPriceTool(BaseTool): 一个用于获取指定股票最新价格的工具。 name: str get_stock_price description: str 根据股票代码如AAPL, 00700.HK获取实时股价。 stock_code: str Field(..., description股票的交易代码) def _run(self, stock_code: str) - str: # 这里模拟一个API调用 # 实际应用中你会在这里集成雅虎财经、Alpha Vantage等数据源 import random price round(50 random.random() * 100, 2) return f股票 {stock_code} 的最新价格为 ${price} USD。 # 将工具注册到智能体 agent.register_tool(GetStockPriceTool())避坑指南工具的安全性与稳定性输入验证与清理任何来自用户或LLM的输入在传入工具前都必须进行严格验证和清理防止注入攻击如SQL注入、命令注入。设置资源与超时限制对于可能耗时的操作如网络请求、复杂计算务必设置超时和资源使用上限避免智能体“卡死”。错误处理与友好反馈工具内部应有完善的try-catch机制并将捕获的错误转化为Orchestrator和LLM能理解的格式而不是直接抛出晦涩的异常。2.3 模块三Memory记忆—— 智能体的经验与上下文没有记忆的对话是苍白无力的。Memory模块让智能体能够记住之前的交互历史从而实现连贯的多轮对话和基于上下文的决策。Hermes提供了多种记忆存储后端。记忆的层次与实现对话历史Conversation Memory最基础的记忆存储用户与智能体的一问一答。通常使用Token-aware的窗口记忆只保留最近N轮或最近X个token的对话以防止上下文过长导致LLM性能下降或成本激增。实体记忆Entity Memory主动提取并存储对话中提到的关键实体信息如人名、地点、项目名、偏好。例如用户说“我喜欢喝美式咖啡”智能体会将{“用户”: “咖啡偏好”: “美式”}存入实体记忆。下次用户说“推荐一杯咖啡”智能体就能利用这个记忆。向量记忆Vector Memory将对话或工具返回的结果转换成向量存入向量数据库如Chroma, Pinecone。当遇到新问题时可以通过语义搜索召回相关的历史片段。这对于处理长文档、知识库问答场景至关重要。配置示例与权衡在config.yaml中记忆配置可能如下所示memory: type: combined # 使用组合记忆 conversation: type: buffer_window window_size: 10 # 保留最近10轮对话 entity: type: redis # 使用Redis持久化实体记忆 host: localhost port: 6379 vector: type: chroma persist_directory: ./chroma_db embedding_model: text-embedding-3-small提示对于大多数应用从“缓冲窗口对话记忆”“简易实体记忆”开始就足够了。向量记忆虽然强大但会引入额外的复杂性和延迟。只有当你的应用需要处理大量非结构化知识时才考虑引入。2.4 模块四Knowledge知识库—— 智能体的外置大脑如果说Memory是短期工作记忆和个人经验那么Knowledge就是智能体随身携带的图书馆或知识手册。这个模块允许你将私有文档、公司wiki、产品手册等数据灌入智能体让它能基于这些特定知识来回答问题。知识库构建流程文档加载与分割支持PDF、Word、TXT、Markdown、网页等格式。关键步骤是文本分割Text Splitting需要根据文档结构按段落、标题进行智能分割避免语义断层。向量化与存储使用嵌入模型Embedding Model将分割后的文本块转换为向量存入向量数据库。检索增强生成RAG当用户提问时先从知识库中检索出最相关的几个文本块然后将“问题相关上下文”一起交给LLM生成答案。这能显著提高答案的准确性和减少幻觉。实操中的核心挑战与解决方案挑战一检索精度不高。可能因为分割策略不佳或嵌入模型不匹配。解决方案尝试不同的分割器如RecursiveCharacterTextSplitter并调整块大小和重叠区间。对于专业领域考虑使用领域微调过的嵌入模型。挑战二上下文过长。检索出的多个文本块可能超出LLM的上下文限制。解决方案采用“Map-Reduce”或“Refine”等高级RAG策略。先让LLM对每个片段生成小结再基于小结合成最终答案。挑战三知识更新。如何让知识库与最新信息同步解决方案为知识库建立版本管理和增量更新机制。对于频繁变动的数据可以将其与工具调用结合例如让智能体先查询最新的API再结合静态知识库回答。3. 三种开箱即用配置方案实战理解了四大模块我们就可以像组装乐高一样用Hermes Agent快速搭建不同用途的智能体。下面三种配置方案覆盖了从简单到进阶的常见场景。3.1 配置一基础问答机器人快速入门这是最简单的配置目标是快速验证想法构建一个能基于给定知识库进行问答的机器人。核心配置要点Orchestrator使用轻量级提示专注于理解问题并从知识库中检索答案。Tools仅配置必要的知识库检索工具。Memory使用简单的对话缓冲记忆维持基本的对话连贯性。Knowledge接入一个准备好的向量知识库。快速启动脚本示例from hermes.agent import HermesAgent from hermes.knowledge import VectorKnowledgeBase from hermes.memory import BufferWindowMemory # 1. 初始化知识库假设已预先构建好 knowledge_base VectorKnowledgeBase(persist_path./my_data_index) # 2. 初始化记忆 memory BufferWindowMemory(window_size5) # 3. 创建智能体 agent HermesAgent( llm_modelgpt-3.5-turbo, # 或使用本地模型 tools[], # 此配置暂不添加其他工具 knowledge_baseknowledge_base, memorymemory, system_prompt你是一个专业的客服助手请严格根据提供的知识库内容回答用户问题。如果知识库中没有相关信息请如实告知不知道不要编造信息。 ) # 4. 运行 response agent.run(你们公司的退货政策是什么) print(response)这个配置的优缺点优点搭建速度极快成本低非常适合做概念验证或处理静态文档问答。缺点功能单一无法处理需要动态信息如天气、股价或执行动作如发邮件的任务。3.2 配置二多功能自动执行助手进阶应用这是最体现Hermes Agent价值的配置。智能体不仅可以问答还能调用各种工具帮你完成实际任务。核心配置要点Orchestrator需要强大的规划和推理能力建议使用GPT-4或Claude-3等高级模型。提示词必须清晰定义所有可用工具及其使用规范。Tools注册一个丰富的工具集如网页搜索、邮件发送、日历管理、数据查询等。Memory需要更强大的记忆如结合实体记忆记住用户的常用信息和偏好。Knowledge可选可作为工具调用的补充。配置示例与工具编排假设我们要构建一个“个人研究助理”它能搜索最新论文、总结内容并保存到笔记中。# config_advanced.yaml agent: llm: gpt-4-turbo system_prompt: | 你是一个AI研究助理。你可以使用以下工具 - web_search(query): 使用搜索引擎查询网络信息。 - read_webpage(url): 读取给定网页的内容。 - summarize_text(text): 总结长文本的核心内容。 - append_to_note(filepath, content): 将内容追加到指定笔记文件。 请根据用户需求规划步骤并使用工具。确保最终输出清晰有用。 tools: - name: web_search class: WebSearchTool params: api_key: ${SEARCH_API_KEY} - name: read_webpage class: WebScraperTool params: timeout: 10 - name: summarize_text class: SummarizationTool # 这可能封装了一个本地摘要模型或API - name: append_to_note class: FileAppendTool params: allowed_directories: [./notes] memory: type: combined conversation: window_size: 12 entity: type: simple # 在内存中存储实体运行示例用户说“帮我找找最近关于‘多模态大模型’的综述文章把主要观点总结一下存到‘research_notes.md’里。” 智能体的执行链可能是web_search(“多模态大模型 综述 2024”)- 从结果中选择最相关的链接 -read_webpage(url)-summarize_text(网页内容)-append_to_note(“./notes/research_notes.md”, 摘要)- 向用户报告完成。3.3 配置三定制化专业领域智能体高阶定制当你要将智能体深度集成到特定业务流中时就需要进行深度定制。这可能涉及自定义工具、专用知识库和特殊的流程控制。案例客户支持工单自动分类与路由智能体需求自动读取客户提交的工单内容判断其所属类别如“账单问题”、“技术故障”、“产品咨询”提取关键实体订单号、错误代码然后根据规则路由给相应的处理团队并生成一个初步的回复模板。定制化工作自定义工具ClassifyTicketTool: 调用一个微调过的文本分类模型或通过精心设计的提示词让LLM分类输出标准化类别。ExtractEntitiesTool: 使用NER模型提取订单号、产品版本等关键信息。QueryCRM Tool: 根据提取的订单号内部调用CRM系统API获取客户历史信息。CreateTicketInSystemTool: 在内部工单系统如Jira, Zendesk中创建格式化工单。定制Orchestrator逻辑系统提示词需要定义严格的工单处理SOP标准作业程序例如“必须先分类再提取实体然后查询客户信息最后创建工单”。集成内部知识库接入产品故障代码手册、常见问题解答FAQ知识库让智能体在生成初步回复时能引用准确信息。实现后处理与验证在工具调用链的最后添加一个“验证”步骤检查创建工单的必填字段是否完整防止流程中断。配置心得 在这种深度定制场景下Hermes Agent的模块化优势尽显。你可以把每个业务步骤封装成一个工具通过Orchestrator的提示词来定义业务流程。关键在于工具设计的原子性和可靠性以及在Orchestrator提示词中明确约束和决策逻辑避免智能体在复杂业务流程中“迷路”。4. 从零到一的部署与调试实战有了配置方案下一步就是让它真正跑起来。这里分享从环境搭建到上线调试的全流程实操经验。4.1 环境准备与依赖管理首先建立一个干净、可复现的Python环境至关重要。我强烈推荐使用uv或poetry这类现代包管理工具而不是直接pip install。# 使用 uv (速度极快) uv init hermes-project cd hermes-project uv add hermes-agent[all] # 安装所有可选依赖 uv add pytest pytest-asyncio # 安装测试框架 # 或者使用 poetry poetry new hermes-project cd hermes-project poetry add hermes-agent关键依赖解析openai/anthropic/litellm: 用于调用大模型API。如果你使用本地模型如通过Ollama部署的Llama 3则需要配置相应的后端。chromadb/qdrant-client: 向量数据库客户端用于知识库和向量记忆。langchain-community: Hermes Agent 在设计上借鉴了LangChain的一些思想并且可以兼容部分LangChain工具这个包提供了丰富的社区工具集成。redis/sqlalchemy: 如果你需要持久化、高性能的记忆存储会用到这些。注意安装时注意Python版本兼容性。Hermes Agent 通常要求 Python 3.9。建议在项目根目录创建requirements.txt或pyproject.toml精确锁定所有依赖的版本避免未来因依赖升级导致的不兼容问题。4.2 配置文件设计与最佳实践不建议把所有配置都硬编码在代码里。使用YAML或JSON配置文件是更专业和可维护的做法。一个典型的config.yaml结构如下# config.yaml hermes: agent: name: MyCustomerServiceAgent llm: provider: openai model: gpt-4o-mini api_key: ${OPENAI_API_KEY} # 使用环境变量 temperature: 0.1 # 降低随机性使输出更稳定 max_tokens: 2000 max_iterations: 10 # 限制工具调用循环次数防止死循环 tools: - name: search_web class: hermes.tools.WebSearchTool params: api_key: ${SERPAPI_KEY} num_results: 5 - name: query_database class: my_custom_tools.DatabaseQueryTool params: connection_string: ${DB_CONN_STR} query_timeout: 30 memory: type: redis config: host: localhost port: 6379 db: 0 key_prefix: hermes:agent1: # 为不同智能体实例设置前缀避免冲突 knowledge: - name: product_manual type: vector loader: directory path: ./docs/product embedding: text-embedding-3-small chunk_size: 1000最佳实践敏感信息分离API密钥、数据库连接字符串等绝对不要写在配置文件中。使用${ENV_VAR}语法从环境变量读取。配置分层可以创建config_base.yaml、config_dev.yaml、config_prod.yaml通过环境变量决定加载哪个方便不同环境切换。参数化将模型名称、温度、最大token数等参数化便于进行A/B测试和性能调优。4.3 核心代码结构与运行逻辑一个健壮的Hermes Agent项目代码结构应该清晰分层my_hermes_app/ ├── config/ │ ├── base.yaml │ └── production.yaml ├── tools/ # 自定义工具目录 │ ├── __init__.py │ ├── database_tool.py │ └── internal_api_tool.py ├── knowledge/ # 知识库加载与处理脚本 │ └── build_kb.py ├── agents/ # 智能体定义目录 │ └── customer_agent.py ├── main.py # 应用主入口 └── .env.example # 环境变量示例文件在agents/customer_agent.py中你可能会这样初始化智能体import os from hermes.agent import HermesAgent from hermes.memory import RedisMemory from my_tools.database_tool import DatabaseQueryTool import yaml def create_agent(config_path: str): with open(config_path, r) as f: config yaml.safe_load(f) # 1. 初始化工具 tools [] for tool_config in config[hermes][tools]: # 动态导入工具类假设配置中写了模块路径 module_path, class_name tool_config[class].rsplit(., 1) module __import__(module_path, fromlist[class_name]) ToolClass getattr(module, class_name) # 实例化工具传入参数 tool_instance ToolClass(**tool_config.get(params, {})) tools.append(tool_instance) # 2. 初始化记忆 memory_config config[hermes][memory] if memory_config[type] redis: memory RedisMemory(**memory_config[config]) # 3. 创建智能体 agent HermesAgent( llm_modelconfig[hermes][agent][llm][model], llm_providerconfig[hermes][agent][llm][provider], llm_params{ temperature: config[hermes][agent][llm][temperature], api_key: os.getenv(OPENAI_API_KEY) }, toolstools, memorymemory, system_promptconfig[hermes][agent].get(system_prompt, ), max_iterationsconfig[hermes][agent].get(max_iterations, 5) ) return agent在main.py中运行方式可以是交互式命令行也可以是FastAPI等Web服务from agents.customer_agent import create_agent import asyncio async def main(): agent create_agent(./config/production.yaml) # 交互式循环 while True: try: user_input input(\n用户: ) if user_input.lower() in [quit, exit]: break response await agent.arun(user_input) # 使用异步接口 print(f\n助手: {response}) except KeyboardInterrupt: break except Exception as e: print(f\n[错误] 处理请求时出错: {e}) if __name__ __main__: asyncio.run(main())4.4 调试、监控与性能优化智能体应用上线后调试和监控是保证其稳定运行的关键。1. 日志记录与追踪务必配置详细的日志记录每一次LLM调用、工具调用和最终输出。这有助于事后分析错误和优化成本。import logging logging.basicConfig(levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s) logger logging.getLogger(__name__) # 在工具调用和LLM调用处添加日志 class MyCustomTool(BaseTool): def _run(self, *args, **kwargs): logger.info(f调用工具 {self.name}参数: {args}, {kwargs}) # ... 工具逻辑 logger.info(f工具 {self.name} 返回: {result}) return result2. 成本监控LLM API调用是主要成本来源。你需要跟踪每个会话的token使用量特别是输入token。大多数SDK如OpenAI会在响应中返回使用量。定期汇总这些数据分析哪些类型的请求最耗token并考虑优化提示词或引入缓存。3. 性能瓶颈排查响应慢可能是工具调用如网络请求慢或LLM本身响应慢。使用异步工具调用如果支持和设置合理的超时时间。对于LLM可以考虑使用更快的模型如GPT-3.5-Turbo进行简单任务路由。工具调用死循环Orchestrator可能陷入“调用工具 - 结果不理想 - 再次调用”的循环。务必设置max_iterations参数如5-10次并在系统提示词中明确要求智能体在多次尝试失败后向用户求助。知识库检索不准检查嵌入模型是否合适调整文本分割的块大小和重叠度或尝试重排序Re-ranking技术来提升检索质量。5. 常见问题与排查技巧实录在实际开发和运维中你会遇到各种各样的问题。这里记录了一些高频问题和我的解决思路。5.1 智能体不调用工具总是“自言自语”现象你明明注册了工具但智能体在回答相关问题时选择用LLM生成一个看似合理但实际是编造的回答而不是调用工具。可能原因与排查工具描述不清检查你为工具定义的name和description是否足够清晰、无歧义。描述应准确说明工具的功能、输入和输出。使用Orchestrator模型能理解的关键词。系统提示词未强调工具使用在给Orchestrator的系统提示词中必须明确指令例如“你必须使用可用的工具来获取真实信息或执行操作。不要凭空想象答案。” 并给出使用工具的少样本示例。LLM温度Temperature过高温度参数控制输出的随机性。过高的温度如0.8以上可能导致模型不遵循指令。尝试将其降低到0.1-0.3增加输出的确定性。工具注册失败检查代码确保工具实例被正确创建并传递给了HermesAgent。在初始化后可以打印agent.get_tools()来确认工具列表。5.2 工具调用结果无法被正确解析或使用现象工具被调用了也返回了结果但智能体似乎“看不懂”这个结果或者基于错误的理解给出了荒谬的后续回答。可能原因与排查工具输出格式不友好工具返回的应该是纯文本或结构简单的JSON。避免返回过于复杂、嵌套深的对象或包含大量无关信息的HTML。最好在工具内部就对原始结果做一次清洗和格式化。结果超出了LLM上下文或处理能力如果工具返回了一篇很长的文章直接塞给LLM可能效果不好。考虑让工具本身具备摘要能力或者设计一个summarize_tool_result工具来预处理长文本。在提示词中训练LLM理解工具输出在少样本示例中不仅要展示如何调用工具还要展示工具返回结果后智能体应该如何分析和利用这个结果。给模型一个“思考过程”的范例。5.3 多轮对话中上下文丢失或混乱现象在长时间的对话中智能体忘记了之前讨论过的关键信息或者将不同话题的上下文混淆了。可能原因与排查对话记忆窗口太小检查BufferWindowMemory的window_size或max_token_limit设置。如果对话轮次多或内容长可能需要增大这个值但要注意LLM的上下文长度总限制。未启用或正确配置实体记忆对于需要长期记住的关键信息如用户姓名、偏好应启用实体记忆。检查实体提取和存储是否正常工作。记忆键Key冲突如果你在同一个服务中运行多个智能体实例并为它们使用同一个记忆后端如Redis需要确保每个实例的记忆会话有唯一的键前缀key_prefix否则记忆会串台。5.4 知识库检索效果不佳答案不准确现象基于知识库的问答经常检索不到相关文档或者检索到的文档片段无法支撑生成准确答案。可能原因与排查文本分割策略不当这是最常见的原因。如果按固定字符数分割可能会把一句话或一个关键表格从中间切断。尝试使用按段落、标题或句子分割的智能分割器并调整chunk_size和chunk_overlap参数。嵌入模型不匹配通用的嵌入模型如text-embedding-ada-002对某些专业领域如法律、医学术语的语义捕捉可能不准。考虑使用在该领域数据上微调过的嵌入模型。检索策略单一简单的向量相似度检索如余弦相似度可能不够。可以尝试混合检索结合关键词检索如BM25和向量检索取长补短。重排序先用向量检索出Top K个结果如20个再用一个更精细的交叉编码器模型对它们进行重排序选出最相关的Top N个如3个。查询扩展对用户原始查询进行同义词扩展或让LLM生成多个相关问题用这些问题并行检索再合并结果。5.5 生产环境下的稳定性与安全考量当智能体从Demo走向生产必须考虑以下问题速率限制与熔断对LLM API和所有外部工具API的调用都要添加速率限制和熔断机制防止因某个服务故障导致智能体线程池被拖垮。可以使用tenacity库实现重试使用circuitbreaker实现熔断。输入输出过滤与审查输入对用户输入进行基本的恶意内容检测和过滤防止提示词注入攻击。输出对智能体生成的内容进行审查特别是当它涉及对外发送消息、执行写操作时。可以设置一个“安全层”对敏感操作进行二次确认或记录审计日志。数据隐私与合规确保智能体处理的数据尤其是通过工具获取的用户数据符合隐私法规。避免在提示词或日志中泄露敏感信息。考虑对输出进行匿名化处理。可观测性与审计记录完整的执行轨迹包括用户输入、LLM的每次请求与响应、每个工具调用的输入输出。这不仅是调试的需要也是满足审计和合规要求的关键。可以考虑将轨迹结构化的存储到数据库中。构建一个成熟的Hermes Agent应用是一个从模块组装到系统调优的持续过程。它没有银弹最好的配置永远取决于你的具体场景。我的建议是从一个最小可行产品开始快速验证核心流程然后根据实际遇到的数据和问题逐个模块进行迭代和深化。记住智能体不是魔法它是一套精密的工程系统你对它的理解越深它为你创造的价值就越大。