智能体本地化开发实战：基于LangChain构建波兰语技能库

1. 项目概述与核心价值

最近在开源社区里，我注意到一个挺有意思的项目，叫DariuszCiesielski/polish-agent-skills。光看这个名字，可能很多朋友会有点摸不着头脑，这到底是做什么的？是教AI说波兰语，还是训练一个波兰的智能体？作为一个在AI应用和智能体开发领域摸爬滚打了十来年的老手，我第一眼看到这个标题，就嗅到了一丝不同寻常的味道。这绝不是一个简单的语言模型微调项目，它背后指向的是一个更具体、更垂直、也更具挑战性的领域：为智能体（Agent）赋予特定于波兰语环境和文化背景的“技能”。

简单来说，这个项目可以理解为一套“工具包”或“技能库”。它的目标不是让一个通用的AI模型（比如GPT）学会用波兰语聊天，而是要让一个能够自主执行任务的智能体，具备在波兰语数字生态中“生存”和“工作”的能力。想象一下，你有一个能帮你自动处理邮件的智能体，但如果它看不懂波兰语的邮件格式、不理解波兰公司常用的发票术语、或者无法与波兰本地的在线银行或政务系统交互，那它在波兰市场就寸步难行。polish-agent-skills项目要解决的，正是这类问题。

这个项目的价值，对于以下几类朋友尤其突出：

• 面向波兰市场的开发者或创业者：如果你正在开发一款需要与波兰本地服务（如银行API、电商平台、政府门户）集成的SaaS产品，或者想为波兰用户提供自动化服务，这个项目能为你节省大量从头构建本地化智能体能力的时间。
• AI智能体研究者与爱好者：对于想深入研究智能体在特定语言和文化场景下能力边界的朋友，这是一个绝佳的案例和实验平台。你可以看到如何将语言理解、API调用、流程逻辑封装成可复用的“技能”。
• 企业内部的流程自动化团队：许多跨国公司在波兰设有分支机构，内部流程自动化常常卡在本地化适配上。这个项目提供的思路和可能的基础组件，能启发如何构建跨语言的、具备本地化能力的办公自动化智能体。

接下来，我将深入拆解这个项目可能涉及的核心技术栈、设计思路、实操难点以及我基于经验的一些扩展思考。

2. 项目核心架构与设计思路拆解

一个以“国家/语言”命名的Agent Skills项目，其架构设计必然要围绕“本地化”和“技能模块化”两个核心展开。我们不能把它想象成一个单一模型，而应该视为一个由多种组件构成的系统。

2.1 技能（Skills）的定义与分类

在这个上下文中，“技能”远不止是语言翻译。我认为它至少包含以下几个层次：

1. 语言理解与生成技能：这是最基础的。但不仅仅是翻译，还包括：

   • 领域术语理解：例如，波兰语中关于金融、法律、医疗的专业词汇和表达习惯。
   • 文化语境理解：理解波兰语中特有的礼貌用语、商业书信格式、甚至是一些网络俚语。
   • 结构化信息抽取：从波兰语的文本（如邮件、网页、PDF文档）中准确提取出日期、金额、公司名、地址等信息。波兰语的日期格式（DD.MM.YYYY）、数字书写习惯（千位分隔符是空格，小数点是逗号）都与英语不同。

2. API交互与集成技能：智能体需要与外部世界交互。在波兰，这意味着要适配本地服务。

   • 银行与支付API：像mBank、PKO BP、BLIK等波兰主流银行或支付服务商的接口规范、认证方式（通常涉及独特的Token或证书机制）。
   • 政务与社保API：与ePUAP（波兰政务平台）、ZUS（社保机构）等系统交互的能力。这些API通常有复杂的、基于波兰语文档的SOAP或REST规范。
   • 电商与物流API：Allegro、OLX等波兰本土电商平台，以及InPost、DPD等物流公司的订单、物流跟踪接口。

3. 流程与逻辑技能：将多个基础操作组合成完成特定任务的流程。

   • “自动开具波兰增值税发票”技能：涉及理解订单信息、调用波兰税务局认可的发票生成服务、填充正确的波兰语字段、并发送给客户。
   • “波兰公司注册进度查询”技能：模拟用户登录CEIDG或KRS（波兰商业注册中心）网站，查询并解读公司注册状态。
   • “波兰本地新闻摘要”技能：从指定的波兰语新闻网站抓取内容，进行关键信息提取和摘要生成。

项目的设计思路，很可能采用“插件化”或“工具调用（Tool Calling）”的架构。一个核心的智能体大脑（可能基于某个LLM）负责理解用户意图和规划任务，然后调用注册在技能库中的具体“技能工具”来执行。每个技能都是一个独立的模块，封装了特定的语言处理逻辑、API调用代码和错误处理机制。

2.2 技术栈选型考量

基于上述架构，我们可以推测其技术栈可能包含以下部分：

• 智能体框架：为了高效管理技能和任务流，项目很可能会基于一个成熟的智能体框架进行开发。目前主流的选择包括LangChain、LlamaIndex或AutoGen。LangChain在工具调用和链式编排上非常灵活；LlamaIndex擅长与各种数据源连接；AutoGen则专注于多智能体协作。选择哪一个，取决于项目更侧重流程自动化、数据查询还是复杂协作。
  • 为什么可能是LangChain：考虑到技能需要被封装成标准的“Tool”供LLM调用，LangChain的@tool装饰器和Tool类提供了非常直观的抽象，而且其生态中有大量现成的工具和示例，便于快速集成波兰语相关的工具。
• 大语言模型（LLM）核心：这是智能体的“大脑”。选择需要考虑：
  • 多语言能力：虽然目标是波兰语技能，但智能体可能需要理解英语指令或处理多语言输入。因此，一个强大的多语言模型是基础，例如GPT-4、Claude 3或开源的Llama 3（其多语言版本）。
  • 本地部署与成本：如果涉及敏感的金融或政务数据，可能需要本地部署的模型。波兰语属于西斯拉夫语系，一些在斯拉夫语料上训练过的开源模型可能表现更佳，如Platypus的一些变体或专门针对波兰语优化的GPT-NeoX衍生模型。
• 本地化处理库：这是项目的“肌肉”。
  • 文本处理：spacy需要有支持波兰语的模型（如pl_core_news_md），用于分词、词性标注、命名实体识别（NER）。波兰语的语法复杂，格变化多，一个好的NER模型至关重要。
  • 日期、数字、地址解析：需要定制或利用如dateparser（配置波兰语locale）、phonenumbers（波兰电话号码格式）等库，并自行编写处理波兰特有格式（如“5 grudnia 2023 r.”）的解析器。
• API客户端与认证管理：这是项目的“手脚”。需要为每个集成的波兰服务编写专用的API客户端，并安全地管理认证信息（OAuth tokens, API keys, certificates）。可能会用到requests、httpx库，并配合pydantic来严格定义请求/响应模型。

注意：与波兰金融或政务API集成时，安全是重中之重。私钥、证书绝不能硬编码在代码中，必须通过环境变量或安全的密钥管理服务来传递。此外，许多波兰API要求使用符合当地法规的电子签名（podpis elektroniczny），这部分集成的复杂性非常高。

3. 核心技能模块的深度实现解析

让我们以两个假想的、但极具代表性的技能为例，深入剖析其实现细节和可能遇到的“坑”。

3.1 技能一：波兰语发票信息提取器

这个技能的目标是：输入一张波兰语发票（图片或PDF），输出结构化的JSON数据，包括卖方、买方、总金额、增值税号、日期等。

实现步骤与难点：

1. 文档预处理：

   • 如果是PDF，使用pdfplumber或PyMuPDF提取文本。波兰语发票常用表格，需注意表格结构的保持。
   • 如果是图片，使用OCR。这里有一个大坑：通用OCR（如Tesseract）对波兰语特殊字符（如ą, ć, ę, ł, ń, ó, ś, ź, ż）的识别准确率可能不高。解决方案是使用Tesseract时，明确指定波兰语语言包（-l pol），或者考虑使用商业OCR服务（如Google Vision, Azure OCR），它们对多语言的支持通常更好，但成本也更高。

2. 关键字段的定位与提取：

   • 不能依赖固定的文本位置，因为每家公司的发票模板都不同。需要结合关键词和正则表达式。
   • 示例：提取增值税号（NIP）。波兰NIP格式是10位数字，通常前面有“NIP:”标签。但变体很多：“NIP”， “Identyfikator podatkowy NIP”， 甚至直接写一串数字。

   import re def extract_nip(text): # 尝试匹配明确的“NIP：”后跟10位数字 nip_patterns = [ r'NIP\s*[:\-]?\s*(\d{10})', r'Identyfikator podatkowy\s*NIP\s*[:\-]?\s*(\d{10})', # 更激进的：寻找10位连续数字，但前后可能有空格或标点，需谨慎避免误匹配 r'(?<!\d)(\d{10})(?!\d)' ] for pattern in nip_patterns: match = re.search(pattern, text, re.IGNORECASE) if match: # 简单的校验：波兰NIP有固定的校验和算法，这里可以加入验证 if validate_nip(match.group(1)): return match.group(1) return None def validate_nip(nip): # 简化的NIP校验和计算示例（实际算法更复杂） weights = [6, 5, 7, 2, 3, 4, 5, 6, 7] if len(nip) != 10 or not nip.isdigit(): return False try: checksum = sum(int(nip[i]) * weights[i] for i in range(9)) % 11 return checksum == int(nip[9]) except: return False

   • 提取总金额（Kwota całkowita）：需要处理波兰语的数字格式。例如，“1 234,56 zł” 表示 1234.56 波兰兹罗提。正则表达式需要匹配空格作为千分位、逗号作为小数点。

   import locale from decimal import Decimal def parse_polish_amount(amount_str): # 移除货币符号和多余空格 cleaned = amount_str.replace('zł', '').replace('PLN', '').strip() # 替换波兰数字格式：空格->空，逗号->点 normalized = cleaned.replace(' ', '').replace(',', '.') try: return Decimal(normalized) except: # 如果失败，尝试更复杂的解析或使用locale locale.setlocale(locale.LC_ALL, 'pl_PL.UTF-8') try: return Decimal(locale.atof(cleaned)) except: return None

3. 使用LLM进行增强与校验：

   • 当规则和正则表达式无法应对复杂情况时，可以调用LLM进行辅助。将OCR提取的混乱文本片段和明确的指令（“从以下文本中提取卖方公司全称和NIP号”）发送给LLM，让其返回结构化数据。这可以作为后备方案，或用于校验规则提取的结果是否合理。

实操心得：

• 不要追求100%的通用性：为最常用的几种发票模板（如来自SAP、Comarch等流行财务软件的）编写专用解析器，其效果和稳定性远胜于一个试图解析所有模板的“万能”解析器。
• 建立测试用例库：收集几十张真实的、脱敏的波兰语发票（图片和PDF），作为测试集。每实现一个解析逻辑，都跑一遍测试集，确保不会破坏已有的成功案例。
• 日志要详细：记录下每张发票解析时，用了哪个规则，匹配到了什么文本，LLM辅助调用的输入输出是什么。这对于调试和后续改进至关重要。

3.2 技能二：波兰政务网站自动查询器

这个技能的目标是：给定一个波兰公司注册号（KRS）或增值税号（NIP），自动在相应的政务网站上查询并返回公司基本信息。

实现步骤与难点：

1. 选择交互方式：

   • 理想情况：网站提供公开的REST API。但波兰很多政务网站仍以传统网页表单为主。
   • 现实情况：可能需要模拟浏览器操作。这意味着要使用Selenium或Playwright这类自动化测试工具。

2. 使用Playwright进行自动化：

   • Playwright相比Selenium更现代，对动态网页（大量使用JavaScript）的支持更好，且自带浏览器，部署简单。

   from playwright.sync_api import sync_playwright import time def query_company_by_krs(krs_number): with sync_playwright() as p: # 使用Chromium浏览器，可设置为无头模式 browser = p.chromium.launch(headless=True) context = browser.new_context( viewport={'width': 1920, 'height': 1080}, user_agent='Mozilla/5.0 ...' # 设置一个真实的User-Agent ) page = context.new_page() try: # 1. 导航到目标网站，例如商业注册中心查询页 page.goto('https://ekrs.ms.gov.pl/') time.sleep(2) # 等待页面加载，更好的做法是等待特定元素出现 # 2. 接受Cookie（如果弹出） cookie_button = page.locator('button:has-text("Zaakceptuj")').first if cookie_button.is_visible(): cookie_button.click() time.sleep(1) # 3. 定位搜索框并输入KRS号 # 需要仔细查看网页元素，通过选择器定位 search_input = page.locator('input[name="krs"]') search_input.fill(krs_number) # 4. 点击搜索按钮 search_button = page.locator('button:has-text("Szukaj")') search_button.click() # 5. 等待结果加载 page.wait_for_selector('.result-table', timeout=10000) # 等待结果表格出现 # 6. 提取结果数据 # 这里需要根据实际网页结构来解析 company_name = page.locator('.result-row:first-child .company-name').inner_text() address = page.locator('.result-row:first-child .address').inner_text() # ... 提取其他字段 return { 'krs': krs_number, 'name': company_name, 'address': address, # ... } except Exception as e: print(f"查询过程中出错: {e}") # 可以在这里截图，便于调试 page.screenshot(path=f'error_{krs_number}.png') return None finally: browser.close()

3. 应对反爬机制：

   • 频率限制：政务网站通常有严格的访问频率限制。必须在代码中加入延迟（time.sleep），并考虑使用代理IP池来分散请求。
   • 验证码：这是最头疼的问题。如果网站有验证码，自动化难度剧增。可能需要：
     • 寻找是否有无验证码的API接口（有时通过分析网络请求可以发现）。
     • 使用商业验证码破解服务（如2Captcha），但这会增加成本和复杂性，并可能涉及法律风险。
     • 设计流程，在遇到验证码时暂停并通知人工干预。
   • 会话与Cookie管理：有些网站需要维护会话。Playwright的context会自动管理Cookie，但需要注意登录状态的有效期。

实操心得：

• 优先寻找官方API：在写任何爬虫代码之前，花大力气搜索“nazwa serwisuAPI”或“nazwa serwisuweb service”。即使API是付费的，其稳定性和合法性也远胜于脆弱的网页爬虫。
• 尊重robots.txt：检查目标网站的robots.txt文件，明确哪些路径允许爬取。违反它可能导致IP被封，甚至法律问题。
• 设计容错和重试机制：网络不稳定、网站改版是常态。代码中必须对元素定位失败、超时等情况进行妥善处理，并实现指数退避的重试逻辑。
• 数据缓存：对于不常变动的公司基本信息，查询一次后应缓存起来（例如存到SQLite或Redis中），避免对同一数据重复查询，既减轻对方服务器压力，也提高自身响应速度。

4. 技能集成与智能体编排实战

有了一个个独立的技能模块，如何让它们在一个智能体框架下协同工作，是项目成败的关键。这里以 LangChain 为例，展示如何将上述技能集成起来。

4.1 将技能封装为LangChain Tool

每个技能都需要被包装成一个标准的Tool对象，这样LangChain的Agent才能识别和调用它。

from langchain.tools import Tool from typing import Optional, Dict, Any # 假设我们已经实现了上述函数 from polish_invoice_parser import extract_invoice_data from polish_company_query import query_company_by_nip def invoice_parser_tool_func(invoice_file_path: str) -> str: """解析波兰语发票文件，返回结构化信息。输入应为文件路径。""" try: result = extract_invoice_data(invoice_file_path) if result: # 将字典转换为易读的字符串 return f"成功解析发票：\n卖方：{result.get('seller')}\nNIP：{result.get('seller_nip')}\n总金额：{result.get('total_amount')} PLN" else: return "无法解析该发票文件，请检查文件格式或内容。" except Exception as e: return f"解析过程中发生错误：{str(e)}" def company_query_tool_func(nip_number: str) -> str: """根据波兰NIP号查询公司基本信息。""" try: # 这里可以加入缓存检查逻辑 company_info = query_company_by_nip(nip_number) if company_info: return f"查询结果：\n公司名称：{company_info.get('name')}\n注册地址：{company_info.get('address')}\n状态：{company_info.get('status')}" else: return f"未找到NIP为 {nip_number} 的公司信息。" except Exception as e: return f"查询过程中发生错误：{str(e)}" # 创建Tool实例 invoice_tool = Tool( name="PolishInvoiceParser", func=invoice_parser_tool_func, description="""专门用于解析波兰语发票（图片或PDF）的工具。 输入：一个本地文件路径字符串。 输出：发票关键信息的结构化文本摘要，包括卖方、NIP号、总金额等。 如果文件无法读取或解析失败，会返回错误信息。""" ) company_query_tool = Tool( name="PolishCompanyQuery", func=company_query_tool_func, description="""通过波兰NIP（增值税号）查询公司官方信息的工具。 输入：一个有效的10位波兰NIP号码字符串。 输出：公司的注册名称、地址和当前状态。 如果NIP无效或查询失败，会返回相应错误。""" )

4.2 构建并运行智能体

将工具提供给一个LLM，并让LLM根据用户的问题决定何时、如何使用这些工具。

from langchain.agents import initialize_agent, AgentType from langchain_openai import ChatOpenAI # 假设使用OpenAI模型 from langchain.memory import ConversationBufferMemory import os # 1. 初始化LLM llm = ChatOpenAI( model="gpt-4-turbo", # 使用支持函数调用的模型 temperature=0, # 降低随机性，使工具调用更稳定 openai_api_key=os.getenv("OPENAI_API_KEY") ) # 2. 准备工具列表 tools = [invoice_tool, company_query_tool] # 3. 初始化记忆（用于多轮对话） memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) # 4. 创建智能体 # 使用ZERO_SHOT_REACT_DESCRIPTION类型，它适合工具调用，且不需要大量示例 agent = initialize_agent( tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, memory=memory, verbose=True, # 设置为True可以看到Agent的思考过程，便于调试 handle_parsing_errors=True # 优雅地处理解析错误 ) # 5. 运行智能体 # 场景1：用户上传了一张发票，想知道是谁开的 response1 = agent.run("我有一张波兰的发票，文件在 `/invoices/inv_2024_05.pdf`，你能告诉我开发票的公司是谁吗？它的NIP号是多少？") print(response1) # 场景2：用户提供了一个NIP号，想了解这个公司 response2 = agent.run("帮我查一下NIP是 1234567890 的波兰公司情况。") print(response2) # 场景3：一个更复杂的多轮对话 # 用户可能先问公司，然后基于结果再问其他事情，记忆功能就派上用场了。 response3 = agent.run("刚才你查的那家公司，它的注册地址具体是什么？") print(response3)

关键点解析：

• verbose=True：在开发阶段极其重要。它会打印出Agent的“思考链”（ReAct格式），让你看到它是如何理解问题、选择工具、解析工具输出的。这是调试Agent错误行为的最直接方法。
• 工具描述（description）：这是Agent能否正确调用工具的关键。描述必须清晰、准确，说明工具的精确输入格式和预期输出。LLM就是靠这段描述来决定是否以及如何调用它的。好的描述应该像给一个新手程序员写API文档一样。
• 错误处理：工具函数内部必须有完善的try...except，并返回明确的错误信息字符串。LangChain Agent 能处理工具返回的错误，并尝试其他策略或向用户报告。
• 记忆（Memory）：ConversationBufferMemory让Agent能记住之前的对话内容。这在多轮交互中必不可少，例如用户问“上一张发票的总金额是多少？”。对于更复杂的记忆管理（如记住处理过的文件），可能需要自定义Memory类。

5. 部署、监控与持续改进

一个实用的技能库项目，最终需要部署为服务，并建立运维体系。

5.1 部署方案考量

• 方案A：容器化微服务：这是最灵活和可扩展的方案。将智能体核心、每个技能模块（如发票解析服务、公司查询服务）分别打包成Docker容器。使用 Kubernetes 或 Docker Compose 进行编排。
  • 优点：技能更新独立，资源隔离性好，易于横向扩展。
  • 缺点：架构复杂，运维成本高。
• 方案B：单体应用+任务队列：将所有技能和智能体逻辑写在一个应用中，但将耗时的任务（如OCR、网页爬取）提交到像Celery或RQ这样的任务队列中异步执行。
  • 优点：架构简单，适合初期快速迭代。
  • 缺点：应用臃肿，一个技能出错可能影响整体。
• 方案C：Serverless函数：将每个技能部署为独立的云函数（如AWS Lambda， Google Cloud Functions）。智能体作为协调者，通过HTTP调用这些函数。
  • 优点：无需管理服务器，按需付费，自动扩展。
  • 缺点：冷启动可能影响性能，函数运行时间和资源有限制，不适合长时间运行的任务（如复杂的网页爬取）。

对于大多数从0到1的团队，我推荐从方案B开始，快速验证核心价值。当技能数量和调用频率增长后，再逐步向方案A演进。

5.2 监控与日志

没有监控的系统就像在黑暗中开车。必须建立关键指标的监控：

1. 性能指标：
   • 每个技能调用的平均响应时间、P95/P99延迟。
   • 技能调用的成功率、失败率。按失败原因分类（网络超时、解析错误、API限额等）。
2. 业务指标：
   • 发票解析的字段准确率（需要人工标注一部分数据作为验证集）。
   • 公司查询的缓存命中率。
3. 日志聚合：使用ELK Stack（Elasticsearch, Logstash, Kibana）或Loki集中收集和分析日志。确保每条技能调用都有唯一的request_id，串联起所有相关日志，便于问题追踪。
4. 告警：对技能持续失败、响应时间异常飙升、成功率下降等情况设置告警（通过PagerDuty、钉钉、企业微信等）。

5.3 持续改进的飞轮

项目的生命力在于迭代。建立一个数据驱动的改进循环：

1. 收集失败案例：所有解析失败或查询错误的案例，其输入（文件、查询号）和错误信息都应自动存入一个“问题池”数据库。
2. 定期复盘：每周或每两周，团队回顾“问题池”中的案例。分析是规则不够（补充正则表达式）、模型不准（增加训练数据）、还是遇到了全新的场景（需要开发新技能）。
3. 更新与测试：针对发现的问题，更新技能代码或模型。务必在包含历史成功案例的完整测试集上运行回归测试，确保修复旧问题不引入新问题。
4. A/B测试：对于重要的改进（如换用新的OCR引擎），可以实施A/B测试，将一部分流量导向新版本，对比成功率、延迟等指标，用数据决定是否全量上线。

6. 可能遇到的挑战与应对策略

在实际构建和运营这样一个项目时，你会遇到许多预料之中和预料之外的挑战。

挑战一：波兰语语言处理的复杂性

• 问题：波兰语有7个格、丰富的词形变化，同一个词在不同语境下形态差异巨大。简单的关键词匹配经常失效。
• 策略：
  • 深入使用NLP工具：不仅仅用spacy做分词，更要利用其依存句法分析功能，理解句子中“谁对谁做了什么”，这对于提取发票上的买卖双方关系至关重要。
  • 结合规则与机器学习：对于关键实体（如公司名、地址），在规则匹配的基础上，可以训练一个简单的NER模型作为补充。虽然波兰语标注数据难找，但可以从公开的商业注册数据中自动构造一些训练样本。
  • 善用LLM的“软实力”：对于极其不规则的文本，将原始文本和清晰的指令（“请找出下面段落中卖方的公司名称和地址”）交给GPT-4这类大模型，往往能得到令人惊喜的准确结果。虽然成本高、速度慢，但可以作为复杂情况下的“最终手段”。

挑战二：外部API的不可靠性与变更

• 问题：政务网站改版、银行API升级且不通知、接口突然限流或返回非标准错误。
• 策略：
  • 防御性编程：对所有外部调用设置合理的超时和重试。验证响应数据的结构和完整性，而不是盲目相信。
  • 抽象与适配器模式：为同类服务（如所有银行API）定义一个统一的接口。具体的API客户端实现这个接口。这样，当某个银行API变更时，你只需要更换或修改对应的适配器，而不影响调用它的业务逻辑。
  • 建立存根（Stub）和模拟（Mock）数据：在开发和测试环境中，使用模拟数据代替真实API调用。这不仅能加快测试速度，还能在真实API不可用时进行降级演练。

挑战三：法律与合规风险

• 问题：网页爬取可能违反网站服务条款；处理发票涉及财务数据隐私；查询公司信息可能有使用限制。
• 策略：
  • 法律咨询先行：在项目启动前，务必咨询熟悉波兰IT法和数据保护法（RODO，即GDPR在波兰的实施）的律师。
  • 获取明确授权：尽可能与数据提供方（如商业信息提供商）签订正式的数据使用协议。
  • 数据最小化与匿名化：只收集和处理完成任务所必需的数据。在日志、测试集中使用脱敏数据。
  • 清晰的用户协议：如果你的技能库作为服务提供给第三方，必须在用户协议中明确数据来源、使用方式、责任边界。

挑战四：技能组合的复杂性管理

• 问题：随着技能数量增长，如何让智能体准确理解用户意图并选择正确的技能组合（或链式调用）？
• 策略：
  • 设计清晰的技能描述：如前所述，这是基础。
  • 实现技能路由层：在智能体之前，可以加一个轻量级的“路由”分类器。它先对用户query进行粗分类（例如，“这是发票相关问题”、“这是公司查询问题”、“这是复合任务”），再交给相应的专用智能体或技能组合去处理。这可以降低主智能体的决策难度。
  • 编写高质量的系统提示词（System Prompt）：精心设计给LLM的指令，明确它的角色、可用工具的范围、输出格式要求。这是引导智能体正确行为的“宪法”。

构建polish-agent-skills这样的项目，是一个典型的工程与语言、技术与业务深度结合的过程。它没有银弹，需要的是对波兰语环境的深刻理解、扎实的软件工程能力、灵活的问题解决思维，以及最重要的——持续迭代的耐心。从一个小而准的技能开始，比如先完美解决“从标准格式PDF发票中提取NIP和金额”，获得正反馈，再逐步扩展边界，最终才能打造出一个真正能在波兰市场创造价值的智能体技能生态。