企业官网建设流程全解析

1. 项目概述：从“agent-skills”这个词组看懂当前智能体开发的真实水位

“agent-skills”不是某个具体软件、也不是某家公司的产品代号，而是一个正在快速凝聚共识的技术概念组合词——它直指当前大模型应用落地中最关键、也最容易被低估的一环：让AI代理（Agent）真正具备可复用、可编排、可验证的“技能”能力。这个词在最近三个月的开发者社区、技术博客和开源项目讨论中出现频率陡增，背后反映的是整个行业正从“能对话”阶段，集体迈入“能做事”阶段。我过去一年深度参与过多个面向企业场景的Agent系统搭建，从客服工单自动分派、到跨系统数据核验、再到内部知识库动态摘要生成，所有项目最终卡点几乎都落在同一个问题上：怎么让大模型不只是“说得好”，而是“做得准”？答案就藏在“skills”这个看似简单的词里。

它解决的不是“要不要加Agent”的战略问题，而是“怎么让Agent不翻车”的战术问题。比如，一个销售助理Agent需要调用CRM接口查客户历史订单，这本身是个标准API调用；但真正的难点在于：当API返回空结果时，它该重试还是降级查本地缓存？当订单字段缺失关键信息时，它该主动追问用户，还是自行补全默认值？这些判断逻辑、容错策略、上下文感知能力，就是“skill”要封装的核心。它不是写在prompt里的模糊指令，而是像传统软件里的函数模块一样，有明确定义的输入/输出契约、有独立的错误处理路径、有可单独测试的边界条件。所以，“agent-skills”本质上是一套工程化方法论，目标是把大模型的“泛化能力”和传统软件的“确定性执行”拧在一起。适合谁来看？如果你正在用LangChain、LlamaIndex或自研框架搭Agent，却反复遇到“流程跑着跑着就崩了”“同一个任务有时对有时错”“换了个模型就全乱套”这类问题，那这篇内容就是为你写的。它不讲大模型原理，只聚焦在“怎么让Agent稳稳当当地把活干完”这一件事上。

2. 内容整体设计与思路拆解：为什么必须把技能从Agent主脑中剥离出来？

2.1 核心矛盾：大模型的“黑箱推理”与业务系统的“白盒确定性”天然互斥

很多团队一开始做Agent，习惯把所有逻辑揉进一个大提示词里：先让模型理解用户意图，再让它决定调用哪个工具，接着拼接参数、解析返回、最后组织回复。听起来很“智能”，实测下来却极难维护。我见过最典型的案例是某金融风控Agent，初期用单一大提示词处理“查询逾期记录+计算罚息+生成催收话术”全流程。上线两周后，业务方临时要求“对VIP客户免收首日罚息”，开发改了三处prompt，结果导致普通客户罚息计算也出错，回滚后又发现催收话术模板丢失了个性化称呼。问题根源在于：把决策逻辑、业务规则、工具调用全部耦合在LLM的不可控输出里，等于把软件工程里最怕的“隐式依赖”搬进了AI系统。

“agent-skills”设计的第一步，就是物理隔离。我们明确划出两条线：

• Agent主脑（Orchestrator）只负责“调度”：它读取用户输入，基于预设规则或轻量模型判断“此刻需要什么技能”，然后把结构化参数传给对应skill；
• 每个Skill只负责“执行”：它接收标准化输入，执行确定性操作（如HTTP请求、数据库查询、正则提取），返回带状态码的结构化结果，绝不自行决定下一步该做什么。

这种分离不是为了炫技，而是为了解决三个刚性需求：

1. 可测试性：你能对一个“查订单”skill写单元测试，覆盖“正常返回”“超时重试”“字段缺失”“权限不足”等所有分支，但你没法对一个大模型的prompt输出写断言；
2. 可替换性：当CRM系统升级API，你只需重写“查订单”skill的实现，Agent主脑完全不用动；
3. 可观测性：日志里能清晰看到“skill_order_query耗时842ms，返回status=200”，而不是“LLM_output_length=1247 tokens，无法定位失败环节”。

2.2 技能分层架构：不是所有功能都该叫“skill”，分清“原子技能”与“复合技能”

很多团队一上来就定义一堆“技能”，结果越做越乱。关键是要建立分层意识。我们实践中把skill严格分为两类：

• 原子技能（Atomic Skill）：最小可执行单元，无内部逻辑分支，纯IO操作。例如：

  • http_get(url, headers)：只发GET请求，不解析响应；
  • db_select(table, where_clause)：只执行SQL查询，不处理结果格式；
  • regex_extract(text, pattern)：只做正则匹配，不判断匹配是否合理。
    这类skill的特点是：输入输出完全确定，可100%自动化测试，失败原因唯一（网络/权限/语法错误）。

• 复合技能（Composite Skill）：由多个原子技能按确定性逻辑编排而成，可包含简单条件判断和重试。例如：

  • get_customer_order_history(customer_id)：先调http_get查CRM，若失败则调db_select查本地缓存，两次都失败才报错；
  • generate_invoice_summary(invoice_id)：先http_get拉发票PDF，再ocr_parse提取文本，最后llm_summarize生成摘要——但每一步的输入输出契约都严格定义。
    这类skill的价值在于封装了业务规则，但它内部不能调用其他复合skill（避免嵌套失控），所有分支必须有明确的if/else或状态机控制。

提示：一个常见误区是把LLM调用本身做成skill。这是危险的——LLM输出本质是概率性的，不能作为确定性流程的可靠输入。正确做法是：把LLM调用封装在复合skill的末端，且其输出必须经过强校验（如JSON Schema验证、关键词存在性检查）才能进入下一步。

2.3 为什么拒绝“万能skill”？——从一次真实故障看过度抽象的代价

去年帮某电商公司优化售后Agent时，他们有个名为resolve_return_request的万能skill，声称能处理所有退货场景。实际代码里，它根据用户消息关键词动态选择子流程：含“破损”走物流索赔，含“发错”走仓库核查，含“不喜欢”走退款通道。表面看很灵活，但上线后故障率奇高。根本原因在于：关键词匹配是脆弱的。用户说“箱子被压扁了”，关键词匹配失败，直接跳到默认退款流程，而实际该走物流索赔。更糟的是，所有子流程的日志都打在同一个skill名下，运维根本分不清是哪个分支出了问题。

我们重构时做了两件事：

1. 拆分成三个原子skill：initiate_logistics_claim、verify_warehouse_mismatch、process_refund；
2. 在Agent主脑里增加一层轻量分类器（用few-shot prompt+温度=0），专门判断用户意图属于哪一类，再精准调度。
   结果：故障率下降92%，平均处理时长缩短37%，因为每个skill的失败原因都能精确定位到具体环节（如initiate_logistics_claim的物流接口超时）。这印证了一个朴素道理：在AI系统里，过度追求“智能”往往牺牲“可靠”，而业务系统第一要务永远是“可靠”。

3. 核心细节解析与实操要点：定义一个合格skill的七条军规

3.1 军规一：输入输出必须契约化——用JSON Schema代替自然语言描述

很多团队写skill文档，用文字描述“输入参数：订单ID（字符串）、时间范围（ISO8601格式）”。这在开发初期可行，但随着协作人数增加，必然出错。我们强制所有skill的输入输出用JSON Schema定义，并集成到CI流程中。以search_knowledge_baseskill为例：

{ "input_schema": { "type": "object", "properties": { "query": {"type": "string", "minLength": 1, "maxLength": 500}, "category": {"type": "string", "enum": ["policy", "troubleshooting", "faq"]}, "max_results": {"type": "integer", "minimum": 1, "maximum": 20} }, "required": ["query", "category"] }, "output_schema": { "type": "object", "properties": { "results": { "type": "array", "items": { "type": "object", "properties": { "title": {"type": "string"}, "content_snippet": {"type": "string"}, "relevance_score": {"type": "number", "minimum": 0, "maximum": 1} } } }, "total_count": {"type": "integer"} } } }

这个Schema带来的好处是立竿见影的：

• 前端调用时，SDK能自动生成类型安全的参数对象，避免传错字段名；
• 测试时，用jsonschema.validate()能100%拦截非法输入，不用等运行时报错；
• Agent主脑调度时，可静态分析输入要求，提前判断是否需要向用户追问缺失参数（如用户没提category，主脑就主动问“您想查政策、故障处理还是常见问题？”）。

注意：Schema里禁用"additionalProperties": true。这是开放后门——一旦允许额外字段，后续迭代中没人敢删旧字段，导致契约越来越臃肿。

3.2 军规二：错误处理必须穷尽——每个skill至少定义5种错误码

把skill当成传统API来设计，错误码就是它的语言。我们规定每个skill必须预定义以下5类错误码（HTTP状态码映射）：

• 400 Bad Request：输入参数违反Schema（如max_results传了负数）；
• 401 Unauthorized：认证失败（API Key过期、权限不足）；
• 404 Not Found：资源不存在（查不到指定订单）；
• 429 Too Many Requests：触发限流（需在skill内实现指数退避）；
• 500 Internal Error：未预期异常（如数据库连接池耗尽）。

关键在于：所有错误必须返回结构化错误体，包含error_code、error_message、suggestion三个字段。例如：

{ "error_code": "404", "error_message": "Order ID 'ORD-999' not found in CRM system", "suggestion": "Please verify the order ID or check if it belongs to another region" }

这样Agent主脑就能基于error_code做精准恢复：遇到404，可降级查缓存；遇到429，自动等待后重试；遇到500，则记录告警并转人工。如果只返回“查不到订单”这种模糊提示，主脑就只能硬着头皮重试三次然后放弃。

3.3 军规三：超时必须分级——网络IO、LLM调用、本地计算绝不能共用一个timeout

这是踩过最多坑的一条。早期我们给所有skill设统一30秒超时，结果发现：

• http_get调外部API，30秒太长（用户早走了），应设5秒+2次重试；
• llm_summarize调本地小模型，30秒太短（长文档生成可能需45秒），应设60秒；
• regex_extract这种纯CPU操作，30毫秒都算慢，设100毫秒足够。

现在我们的规范是：

• 网络IO类skill：基础超时=3秒，重试次数=2，重试间隔=指数退避（1s, 2s）；
• LLM类skill：超时=模型最大生成时间×1.5（如Qwen2-7B生成上限30s，则设45s），禁用重试（LLM重试结果不可控）；
• 本地计算类skill：超时=50毫秒，超时即熔断，返回500 Internal Error。

实操中，我们在skill基类里内置超时管理器，调用时只需声明类型：

class KnowledgeSearchSkill(Skill): def execute(self, input_data: dict) -> dict: # 自动应用网络IO超时策略 response = self.http_client.get( url=f"{self.kb_api}/search", params=input_data, timeout_policy="network_io" # 触发3s+重试策略 ) return self._parse_response(response)

3.4 军规四：状态必须可追溯——每个skill执行必须生成唯一trace_id

当一个用户请求经过5个skill串联时，如何定位第3个skill的失败原因？靠日志grep？效率太低。我们的方案是：Agent主脑生成全局trace_id，透传给每个skill，skill在日志和返回体中必须携带该ID。例如：

[INFO] [trace_id: abc123] Starting skill 'get_customer_profile' for user U-789 [ERROR] [trace_id: abc123] Skill 'get_customer_profile' failed with 401: Invalid API key [INFO] [trace_id: abc123] Fallback to local cache for skill 'get_customer_profile'

更进一步，在返回体中也嵌入trace_id：

{ "trace_id": "abc123", "results": [...], "execution_time_ms": 124 }

这样，前端展示错误时，可以把trace_id直接提供给用户：“您的请求已记录，追踪号abc123，工程师将在10分钟内处理”。运维排查时，一条命令就能捞出完整链路日志：grep "trace_id: abc123" app.log。没有trace_id的skill，等于在分布式系统里裸奔。

3.5 军规五：幂等性必须默认开启——重复调用不能产生副作用

电商场景下，用户可能因网络抖动连续点击“提交退款”，如果process_refundskill不是幂等的，就会导致同一笔订单被退两次款。解决方案不是靠前端防重，而是每个skill必须自身保证幂等。我们采用“唯一业务ID+状态机”模式：

• 所有涉及写操作的skill，输入必须包含business_id（如订单ID、工单号）；
• skill执行前，先查数据库确认该business_id的当前状态；
• 若状态已是“已退款”，直接返回成功；若状态是“待处理”，才执行退款操作并更新状态。

代码骨架如下：

def process_refund(self, input_data: dict) -> dict: business_id = input_data["order_id"] current_status = self.db.get_status(business_id) if current_status == "refunded": return {"success": True, "message": "Already processed"} elif current_status == "pending": # 执行真实退款逻辑 self.payment_gateway.refund(business_id) self.db.update_status(business_id, "refunded") return {"success": True, "message": "Refund completed"} else: raise SkillError(400, f"Invalid status: {current_status}")

实操心得：幂等性检查必须放在skill最开头，且检查逻辑要尽可能轻量（如只查单表单字段）。曾有个团队把状态检查放在退款操作之后，结果退款成功但状态更新失败，导致下次调用又退一次款——这就是典型的“检查位置错误”。

3.6 军规六：敏感信息必须零日志——API Key、Token、身份证号绝不出现在任何日志

这是安全红线。我们规定：

• 所有skill的输入参数，若含api_key、token、id_card等字段，必须在日志打印前脱敏（替换成***）；
• skill内部调用外部服务时，敏感参数必须通过环境变量或密钥管理服务注入，禁止硬编码或从输入参数直接拼接；
• 返回体中的敏感字段（如用户手机号），必须在skill输出前脱敏（如138****1234）。

更严格的实践是：在skill基类里统一拦截。我们写了一个装饰器：

def sanitize_logs(func): def wrapper(self, input_data: dict): # 脱敏输入日志 safe_input = {k: "***" if k in ["api_key", "token", "id_card"] else v for k, v in input_data.items()} logger.info(f"Calling {func.__name__} with {safe_input}") result = func(self, input_data) # 脱敏输出日志 if isinstance(result, dict) and "phone" in result: result["phone"] = mask_phone(result["phone"]) return result return wrapper

这条军规看似增加开发成本，但一次生产事故的损失远超写几行脱敏代码的时间。某次审计中，我们发现一个未脱敏的调试日志意外上传到公开GitHub，虽未造成实质泄露，但触发了全公司安全复盘——从此所有skill的CI流水线都加入日志扫描步骤，检测到敏感词立即阻断。

3.7 军规七：版本必须显式管理——skill不是写完就扔，要像微服务一样迭代

很多团队把skill当成脚本，改完就上线，结果A项目依赖的send_emailskill升级后，B项目调用就失败。我们的解决方案是：每个skill发布时必须带语义化版本号（v1.2.0），且主脑调度时必须指定版本。例如：

# agent_config.yaml skills: - name: send_email version: "v1.2.0" # 显式锁定版本 endpoint: "https://api.example.com/skills/send_email/v1.2.0"

版本管理带来三个好处：

• 灰度发布：新版本v1.3.0先对10%流量开放，监控错误率达标后再全量；
• 平滑迁移：老项目继续用v1.2.0，新项目用v1.3.0，无需停机；
• 回滚保障：v1.3.0出问题，5分钟内切回v1.2.0，不影响业务。

我们甚至把版本号嵌入skill的HTTP响应头：X-Skill-Version: v1.2.0，方便运维实时确认线上运行版本。没有版本管理的skill，就像没有版本号的API，迟早会成为技术债黑洞。

4. 实操过程与核心环节实现：从零搭建一个可落地的skill注册中心

4.1 第一步：设计skill元数据注册表——用数据库而非配置文件管理技能

把skill信息写在YAML里？初期可以，但团队超过3人后必然混乱。我们直接用PostgreSQL建了一张skill_registry表：

关键设计点：

• input_schema和output_schema用JSONB类型，PostgreSQL原生支持JSON路径查询，比如查“哪些skill支持category参数”：

  SELECT name FROM skill_registry WHERE input_schema @> '{"properties": {"category": {"type": "string"}}}';

• status字段区分三种状态：active可被调度；deprecated标记为废弃，新调用会警告但允许执行；blocked彻底禁用，调用直接返回403。
• 所有变更必须通过INSERT/UPDATESQL执行，禁止手动改表——我们写了CLI工具skillctl封装这些操作，确保每次变更都有审计日志。

4.2 第二步：实现skill网关——统一入口，做协议转换与安全校验

Agent主脑不直接调skill，而是通过一个轻量网关。网关核心职责有三：

1. 协议转换：主脑用gRPC调网关，网关转成skill要求的HTTP/JSON；
2. 安全校验：验证主脑的JWT Token，检查调用方是否有权限使用该skill；
3. 熔断限流：基于name+version维度统计QPS，超阈值自动返回429。

网关用Go编写（性能高、部署简单），核心逻辑伪代码：

func (g *Gateway) HandleSkillCall(ctx context.Context, req *pb.SkillRequest) (*pb.SkillResponse, error) { // 1. 解析JWT，获取调用方身份 caller := parseJWT(req.Token) // 2. 查注册表，确认skill存在且active skill, err := g.db.GetSkill(req.Name, req.Version) if err != nil || skill.Status != "active" { return nil, status.Error(codes.NotFound, "skill not found") } // 3. 权限检查：caller是否在skill的allowed_callers列表中 if !contains(skill.AllowedCallers, caller) { return nil, status.Error(codes.PermissionDenied, "no permission") } // 4. 调用skill HTTP endpoint，带trace_id和超时 httpReq, _ := http.NewRequest("POST", skill.Endpoint, bytes.NewReader(req.Payload)) httpReq.Header.Set("X-Trace-ID", req.TraceID) httpReq.Header.Set("Content-Type", "application/json") client := &http.Client{Timeout: getTimeoutForSkill(skill.Type)} resp, err := client.Do(httpReq) // 5. 统一包装响应，注入trace_id return &pb.SkillResponse{ TraceID: req.TraceID, Payload: respBody, StatusCode: resp.StatusCode, }, nil }

这个网关的存在，让skill可以自由选择技术栈（Python/Java/Node.js），只要暴露HTTP接口就行。主脑完全不用关心skill是用什么语言写的，也不用处理鉴权、限流这些横切关注点。

4.3 第三步：构建skill SDK——让开发者专注业务逻辑，不写样板代码

为了让团队快速开发skill，我们提供了Python SDK。开发者只需继承BaseSkill类，实现execute方法即可：

from skill_sdk import BaseSkill, SkillInput, SkillOutput class SearchKnowledgeBaseSkill(BaseSkill): # 自动从注册表加载input/output schema input_schema = "search_knowledge_base_v1.2.0_input.json" output_schema = "search_knowledge_base_v1.2.0_output.json" def execute(self, input_data: SkillInput) -> SkillOutput: # 开发者只写这一段核心逻辑 results = self.kb_client.search( query=input_data.query, category=input_data.category, limit=input_data.max_results ) return { "results": [{"title": r.title, "content_snippet": r.snippet[:200]} for r in results], "total_count": len(results) } # 一行代码启动HTTP服务 if __name__ == "__main__": SearchKnowledgeBaseSkill().serve()

SDK内部已封装：

• 输入参数自动校验（基于schema）；
• 错误自动转换为标准错误体；
• trace_id自动注入日志；
• 超时策略自动应用；
• 敏感字段自动脱敏。

开发者提交代码后，CI流水线自动：

1. 构建Docker镜像；
2. 推送到私有Registry；
3. 调用skillctl register将元数据写入注册表；
4. 发送Webhook通知网关刷新缓存。
   整个过程5分钟内完成，开发者真正写的只有业务逻辑。

4.4 第四步：实现技能健康度看板——用真实数据驱动运维决策

没有监控的skill就是定时炸弹。我们用Prometheus+Grafana搭建了技能健康度看板，核心指标有四个：

• 成功率（Success Rate）：2xx响应数 / 总调用数，阈值≥99.5%；
• P95延迟（P95 Latency）：95%请求的耗时，阈值≤1s（网络IO类）或≤5s（LLM类）；
• 错误分布（Error Breakdown）：按error_code分组的饼图，快速定位是401多还是500多；
• 流量趋势（Traffic Trend）：每小时调用量折线图，突增可能意味着前端bug，突降可能意味着业务下线。

看板不只是展示数据，更要驱动行动。我们设置了告警规则：

• 成功率<99%持续5分钟 → 企业微信告警给负责人；
• P95延迟>2s持续10分钟 → 自动触发skillctl rollback回滚到上一版本；
• 401错误占比>30% → 自动发送邮件提醒运维检查API Key轮换。

有一次，send_smsskill的401错误突然飙升，看板自动告警，运维发现是短信服务商密钥过期，15分钟内完成续期——如果没有这个看板，可能要等用户投诉才发觉。

4.5 第五步：落地效果对比——重构前后关键指标变化

我们选取了某银行智能客服Agent的“账户余额查询”流程作为对照组，对比重构前后数据（统计周期：30天）：

最显著的变化是错误率从“不可知”变为“可归因”。重构前，73%的失败case无法定位到具体环节；重构后，98%的失败能精确到某个skill的某个错误码。这意味着：以前是“AI又抽风了”，现在是“get_account_balanceskill的401错误率超标，去查密钥轮换日志”。

5. 常见问题与排查技巧实录：那些文档里不会写的实战经验

5.1 问题一：skill调用返回500，但日志里只显示“Internal Server Error”，怎么快速定位？

这是最常被问的问题。表面看是skill崩溃，但根源可能在五个层面。我们总结了“五层排查法”，按顺序执行：

1. 网关层：查网关日志，过滤trace_id，看是否在转发前就报错（如JWT解析失败、权限拒绝）；
2. 网络层：用curl -v直接调skill endpoint，绕过网关。如果仍500，说明是skill自身问题；
3. skill入口层：查skill启动日志，看是否加载失败（如数据库连接串错误、环境变量缺失）；
4. 执行层：查skill的/health接口，如果返回500，说明初始化失败（如Redis连接池未创建）；
5. 业务层：查skill的详细错误日志，重点看panic堆栈或未捕获异常。

实操心得：我们给所有skill强制添加/health和/metrics端点。/health只检查依赖服务连通性（DB、Redis、外部API），不执行业务逻辑；/metrics暴露Prometheus指标。运维第一反应永远是curl http://skill-host:8000/health，3秒内就能排除80%的环境问题。

5.2 问题二：复合skill里调用原子skill失败，该重试还是降级？有没有决策树？

没有银弹，但有可落地的决策树。我们基于错误码和业务影响制定了规则：

关键点：重试必须带退避，且总耗时不超复合skill的P95延迟阈值。例如，get_customer_profile复合skill的P95是1.5秒，那么它内部所有重试加起来不能超过1.5秒，否则主脑会超时中断。

5.3 问题三：如何测试一个skill的幂等性？有没有自动化方案？

手动测试幂等性效率极低。我们开发了幂等性测试工具idempotency-tester，原理很简单：

1. 用合法参数调用skill一次，记录返回体和数据库状态；
2. 用相同参数重复调用N次（N=100）；
3. 检查每次返回体是否完全一致（JSON diff）；
4. 检查数据库中该业务ID的状态是否只变更一次。

工具输出报告示例：

Test: process_refund (order_id=ORD-123) ✓ Return body identical across 100 calls ✓ Database status changed only once (pending → refunded) ✓ No side effects detected (email count unchanged, ledger entries = 1) → PASSED

注意：测试必须在真实数据库上运行，内存数据库无法验证事务一致性。我们CI流水线里，每个skill的PR都必须通过幂等性测试，否则禁止合并。

5.4 问题四：skill版本升级后，如何确保Agent主脑无缝切换？

最大的风险是“新skill已上线，但主脑配置没更新，还在调旧版”。我们采用“双写+灰度”策略：

• 双写阶段：新版本v1.3.0发布后，注册表里同时存在v1.2.0（status=active）和v1.3.0（status=active）；
• 灰度阶段：主脑配置里，send_email的version字段设为v1.2.0,v1.3.0（逗号分隔），网关按权重路由（如90%到v1.2.0，10%到v1.3.0）；
• 验证阶段：看板监控v1.3.0的成功率、延迟，达标后调整权重至100%；
• 清理阶段：v1.2.0确认无流量后，将其status改为deprecated，30天后blocked。

这个过程全自动，运维只需执行一条命令：skillctl rollout --name send_email --from v1.2.0 --to v1.3.0 --ramp-up 10。

5.5 问题五：当多个skill需要共享状态（如会话ID、用户偏好），该怎么设计？

禁止skill之间直接通信！所有共享状态必须通过主脑透传。我们定义了context对象，作为每个请求的上下文载体：

class RequestContext: def __init__(self, trace_id: str, user_id: str, session_id: str): self.trace_id = trace_id self.user_id = user_id self.session_id = session_id self.preferences = {} # 用户偏好，如language="zh-CN" self.cache = {} # 临时缓存，如"customer_profile"={"name":"张三","level":"VIP"} # 主脑在调度时注入 context = RequestContext(trace_id, user_id, session_id) skill_result = skill.execute(input_data, context=context) # skill内部可读取/写入 def execute(self, input_data: dict, context: RequestContext): if context.preferences.get("language") == "zh-CN": return self._get_chinese_response(input_data) else: return self._get_english_response(input_data)

关键原则：context只读不写，除非是明确设计的缓存字段。preferences由主脑初始化（从用户档案读取），cache由skill按需填充（如get_customer_profileskill填入profile数据，后续skill可直接用）。这样既解耦，又保证状态一致性。

6. 最后一点个人体会：别把skill当成技术玩具，它是业务稳定性的最后一道防线

我见过太多团队把