1. 项目概述当AI不再是工具而是你的“数字同事”最近和几个做工程效能和AI应用开发的朋友聊天话题总绕不开一个词Harness Engineering。这词听起来挺唬人但说白了就是怎么用一套系统化的方法把AI这个“新员工”管起来、用起来让它别添乱还能真干活。我们聊到了iSparta、Harness这些平台也提到了像“Caveman”原始人这样的比喻——形容那些还在用最原始、手工方式对接AI的开发者。这让我觉得是时候把这些碎片化的思考整理一下了。这不是一篇技术评测也不是某个框架的安装教程。我想聊的是在2026年的这个节点作为一个开发者、一个技术团队的负责人甚至只是一个对AI感兴趣的个体我们该如何与AI协作而不仅仅是使用它。当Claude Code能帮你写代码各种Agent框架承诺自动化一切时你的角色是什么你的价值又在哪里这篇文章就是我结合最近的实践和观察梳理的一份“AI时代的生存指南”。它关乎工程方法更关乎思维模式的转变。2. 核心概念拆解从工具到协作者的范式迁移要理解我们面临的转变得先厘清几个关键概念。它们不仅仅是热词更是新范式的基石。2.1 Harness Engineering给AI套上“缰绳”Harness Engineering我更喜欢把它翻译成“驾驭式工程”。它的核心思想是AI模型尤其是大语言模型本身是不可靠、不确定的“黑盒”。你不能像调用一个确定性的APIsum(a, b)永远返回ab那样去使用它。直接、裸调AI接口就像试图徒手驾驭一匹野马结果完全不可预测。Harness工程要做的就是为这匹“野马”设计一套缰绳、马鞍和控制系统。这套系统通常包括提示词Prompt工程与管理这不是简单地问问题而是设计一套可复用、可测试、可版本化的“指令集”。就像给AI写一份清晰、无歧义的工作说明书。上下文Context管理如何高效地为AI提供它完成任务所需的知识你的代码库、文档、数据库schema。这涉及到检索、裁剪、注入确保信息相关且不超载。输出结构化与验证强制AI的输出符合特定格式如JSON并自动进行有效性校验语法检查、业务规则校验。避免得到一段无法解析的散文。流程编排Orchestration将多个AI调用、工具使用查数据库、调用API、人工审核节点编排成一个可靠的工作流。Think of it as a “circuit breaker” and “retry logic” for AI operations.评估与监控如何量化AI任务完成的好坏建立评估体系精确度、相关性、成本并监控生产环境中的表现实现持续改进。一个常见的误区是认为Harness就是某个叫“Harness”的CI/CD平台。虽然那个平台确实涉及自动化但Harness Engineering是一种方法论你可以用LangChain、LlamaIndex、甚至是自定义框架来实现它。它的对立面就是下一节要说的“Caveman”模式。2.2 Caveman模式我们为何还在“钻木取火”“Caveman”洞穴人是我和朋友调侃时用的词形容这样一种开发状态每个开发者都在自己的编辑器里打开一个ChatGPT或Claude的网页窗口手动复制粘贴代码、错误信息、需求描述然后等待回复再手动把代码贴回IDE。整个流程是断裂的、手动的、不可复现的。这种模式的问题显而易见上下文丢失每次对话都是新的开始AI不了解项目全貌。效率低下频繁的切换和复制粘贴打断了深度工作流。知识无法沉淀成功的提示词和解决方案散落在私人聊天记录里无法团队共享。质量不可控输出完全依赖当次提问的水平和模型的“心情”没有自动化测试和验证。很多团队引入了Claude Code或类似IDE插件以为解决了问题但其实只是把网页窗口搬进了IDE本质仍是“增强版的Caveman”。除非你为Claude Code精心配置技能Skill、提供项目级上下文否则它依然是个孤立的工具。2.3 Agent从单一指令到自主目标Agent智能体是另一个关键概念。你可以把它理解为一个配备了“大脑”LLM、“感知器”工具调用能力和“记忆”上下文的自主程序。它与简单调用AI完成单一任务如“翻译这句话”有本质区别。一个真正的Agent应该具备目标导向你给它一个高级目标“优化这个API的响应速度”它会自己拆解任务。工具使用它能主动调用外部工具比如运行测试、查询文档、执行Git命令、调用分析API。持续学习与记忆能在与环境和用户的互动中积累信息调整策略。Harness Engineering 与 Agent 的关系是什么我的理解是Harness Engineering 是构建可靠、可维护Agent的必由之路。你不能直接扔一个目标给一个“裸”的LLM就叫它Agent那会是一场灾难。你需要用Harness的那套方法——清晰的规划、可靠的工具调用、严格的输出校验、周密的流程编排——来打造这个Agent的“身体”和“神经系统”让它的“大脑”能够安全、有效地工作。3. 实战架构构建你的第一个“可驾驭”AI工作流理论说再多不如动手搭一个。我们不追求一步到位打造全能Agent而是先构建一个解决实际问题的、具备Harness工程思想的最小可行工作流。假设我们是一个移动应用团队经常需要处理用户通过App提交的模糊反馈比如“闪退”、“卡顿”、“不好用”。3.1 场景定义与工具选型目标自动化处理用户反馈工单。输入是一段自然语言描述输出是结构化数据问题分类、严重等级、可能的原因模块、建议的指派负责人并自动创建或更新Jira工单。为什么选这个场景价值明确解放客服或产品经理的重复劳动。输入非结构化非常适合LLM处理。输出需结构化能很好地体现Harness工程中“输出校验”的价值。涉及外部系统需要连接Jira API体现了“工具使用”。工具栈选择基于常见、开源原则核心LLMClaude 3.5 Sonnet (via API)。选择原因是其在推理、指令遵循和输出结构化方面表现均衡稳定。注意这里我们使用API而非Claude Code插件是为了实现流程自动化。应用框架LangChain。虽然有点“重”但其对工具调用、链式编排的支持非常成熟社区活跃能快速搭建原型。对于简单任务也可以直接用OpenAI的Assistant API或自己写封装。开发语言Python。生态完善LangChain支持最好。外部工具Jira REST API (使用jira库)。上下文管理暂时用简单的向量数据库Chroma存储历史工单和知识库文档用于检索增强生成RAG。3.2 核心环节一设计抗脆弱的提示词系统直接写一个长提示词是Caveman做法。我们需要把它工程化。第一步提示词模板化我们创建一个prompt_templates.py文件# prompt_templates.py FEEDBACK_CLASSIFICATION_PROMPT 你是一个资深的移动应用质量分析专家。请严格遵循以下步骤分析用户反馈 分析步骤 1. **问题分类**从以下类别中选择最贴切的一项{categories}。 2. **严重等级**判断严重性从 P0崩溃/数据丢失到 P3轻微UI问题中选择。 3. **根因推测**结合上下文中的知识近期版本日志、已知问题列表推测最可能引发该问题的代码模块或系统组件如“支付模块”、“iOS视频播放器”、“Android后台服务”。如果上下文无相关信息则写“需进一步排查”。 4. **建议指派**根据问题模块建议将此工单指派给哪个开发小组或负责人如“iOS客户端组-张三”、“后端API组-李四”。如果无法确定则写“待定”。 /分析步骤 输出格式要求 你必须以纯JSON格式输出且只包含以下键 {{ category: 选择的结果, severity: P0/P1/P2/P3, root_cause_module: 推测的模块, suggested_assignee: 建议的负责人或组 }} /输出格式要求 用户反馈 {user_feedback} /用户反馈 相关上下文 {retrieved_context} /相关上下文 为什么这么设计结构化指令用XML风格标签分析步骤清晰分隔指令块帮助LLM理解结构。变量注入{categories},{user_feedback},{retrieved_context}是变量将在运行时填充。这使得提示词可配置、可复用。严格输出约束明确要求纯JSON并给出了Schema。这是避免“幻觉”和解析错误的关键。角色设定赋予LLM一个具体角色引导其思维方式。第二步实现上下文检索RAG我们不会把整个知识库都塞给LLM。而是先检索最相关的信息。# context_retriever.py from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.text_splitter import RecursiveCharacterTextSplitter class FeedbackContextRetriever: def __init__(self, persist_directory./chroma_db): self.embeddings OpenAIEmbeddings(modeltext-embedding-3-small) # 使用小模型以节约成本 self.vectorstore Chroma(persist_directorypersist_directory, embedding_functionself.embeddings) self.text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) def add_documents(self, documents): 向知识库添加文档如版本发布说明、已知问题列表 splits self.text_splitter.split_documents(documents) self.vectorstore.add_documents(splits) def retrieve(self, query: str, k: int 3): 检索与用户反馈最相关的k个文档片段 if not self.vectorstore._collection.count(): return 暂无相关上下文信息。 docs self.vectorstore.similarity_search(query, kk) return \n---\n.join([doc.page_content for doc in docs]) # 初始化并添加一些初始知识 retriever FeedbackContextRetriever() # 假设我们有一些已知问题文档 known_issues [ 版本2.1.0iOS端在低电量模式下视频播放器可能卡顿。, 版本2.0.5Android支付回调在某些网络环境下有概率失败。, 通用用户头像上传组件不支持HEIC格式图片会提示‘格式错误’。 ] # 将文档转换为LangChain Document对象后添加此处略实操心得一RAG的陷阱刚开始做RAG时最容易犯的错误是“检索即结束”。实际上检索到的上下文质量直接影响最终效果。我们踩过的坑分块大小chunk_size500是个经验值。对于技术文档可以稍大800对于对话记录应该更小200。需要根据内容调整。检索数量k不是越多越好。k3或4通常足够。太多无关信息会干扰LLM增加成本并可能降低准确性。元数据过滤生产环境中一定要为文档块添加元数据如“文档类型发布说明”、“版本号2.1.0”检索时进行过滤确保上下文的新鲜度和相关性。3.3 核心环节二构建具有自检能力的处理链现在我们将提示词、检索器、LLM和输出解析组合成一个“链”。# feedback_processing_chain.py from langchain.chains import LLMChain from langchain.prompts import PromptTemplate from langchain.output_parsers import StructuredOutputParser, ResponseSchema from langchain_anthropic import ChatAnthropic import json from .prompt_templates import FEEDBACK_CLASSIFICATION_PROMPT from .context_retriever import retriever # 1. 定义我们期望的输出结构与提示词中的JSON对应 response_schemas [ ResponseSchema(namecategory, description问题分类), ResponseSchema(nameseverity, description严重等级 P0-P3), ResponseSchema(nameroot_cause_module, description推测的根因模块), ResponseSchema(namesuggested_assignee, description建议的指派负责人) ] output_parser StructuredOutputParser.from_response_schemas(response_schemas) # 2. 从模板创建PromptTemplate并自动获取格式指令 prompt_template PromptTemplate( templateFEEDBACK_CLASSIFICATION_PROMPT, input_variables[user_feedback, retrieved_context], partial_variables{ categories: 崩溃/闪退 | 性能卡顿 | 功能异常 | UI/UX问题 | 内容相关 | 其他, format_instructions: output_parser.get_format_instructions() # 将格式指令也注入模板 } ) # 3. 初始化LLM llm ChatAnthropic(modelclaude-3-5-sonnet-20241022, temperature0.1) # 低temperature保证输出稳定 # 4. 创建链 chain LLMChain(llmllm, promptprompt_template, output_parseroutput_parser) def process_feedback(feedback_text: str): 处理用户反馈的主函数 # Step A: 检索上下文 context retriever.retrieve(feedback_text) # Step B: 运行链 try: result chain.run({ user_feedback: feedback_text, retrieved_context: context }) # result 已经是一个字典了因为output_parser会处理 classification_result result except Exception as e: # 处理解析错误可能是LLM没有按照格式输出 classification_result { category: 解析失败, severity: P3, root_cause_module: fLLM输出格式错误: {str(e)}, suggested_assignee: 系统管理员 } # Step C: 业务逻辑校验后置守卫 validated_result validate_and_correct_result(classification_result, feedback_text) return validated_result def validate_and_correct_result(result: dict, original_feedback: str) - dict: 对LLM的输出进行业务规则校验和修正 # 示例规则1如果反馈中包含“闪退”、“崩溃”等词但分类不是“崩溃/闪退”则强制修正 crash_keywords [闪退, 崩溃, crash, force close] if any(keyword in original_feedback for keyword in crash_keywords) and result[category] ! 崩溃/闪退: result[category] 崩溃/闪退 result[severity] max(result[severity], P1) # 至少是P1 result[root_cause_module] 疑似崩溃模块自动修正 # 示例规则2严重等级逻辑校验 if result[severity] not in [P0, P1, P2, P3]: result[severity] P3 # 默认最低 # 可以添加更多规则如根据模块映射负责人等... return result这就是Harness的核心我们不是相信LLM的一次性输出而是用output_parser进行结构化解析用validate_and_correct_result函数作为“后置守卫”强制执行业务规则。即使LLM“胡言乱语”我们也能得到一个符合最低标准的结构化结果。3.4 核心环节三集成外部工具与行动执行得到结构化数据后下一步是创建Jira工单。这里我们实现一个简单的工具。# jira_tool.py from jira import JIRA import os class JiraIntegrationTool: def __init__(self): self.jira_server os.getenv(JIRA_SERVER) self.jira_username os.getenv(JIRA_USERNAME) self.jira_api_token os.getenv(JIRA_API_TOKEN) self.client JIRA(serverself.jira_server, basic_auth(self.jira_username, self.jira_api_token)) self.project_key APP # 你的Jira项目Key def create_issue(self, summary, description, issue_typeBug, priorityNone, assigneeNone): 在Jira中创建问题 issue_dict { project: {key: self.project_key}, summary: summary, description: description, issuetype: {name: issue_type}, } if priority: # 映射我们的P0-P3到Jira优先级 priority_map {P0: Highest, P1: High, P2: Medium, P3: Low} issue_dict[priority] {name: priority_map.get(priority, Medium)} if assignee and assignee ! 待定: # 注意Jira可能需要特定的账户ID issue_dict[assignee] {name: assignee} try: new_issue self.client.create_issue(fieldsissue_dict) return f工单创建成功: {new_issue.key} - {new_issue.permalink()} except Exception as e: return f工单创建失败: {str(e)} # 在主流程中集成 from jira_tool import JiraIntegrationTool def full_feedback_pipeline(feedback_text: str): 完整的反馈处理流水线 # 1. 分类与解析 analysis process_feedback(feedback_text) # 2. 准备Jira工单内容 summary f[AI分类-{analysis[category]}] {feedback_text[:50]}... # 摘要 description f *用户原始反馈*: {feedback_text} *AI分析结果*: - 分类: {analysis[category]} - 严重等级: {analysis[severity]} - 疑似模块: {analysis[root_cause_module]} - 建议指派: {analysis[suggested_assignee]} *此工单由AI反馈处理系统自动创建。* # 3. 创建工单 jira_tool JiraIntegrationTool() result_msg jira_tool.create_issue( summarysummary, descriptiondescription, priorityanalysis[severity], assigneeanalysis[suggested_assignee] ) # 4. 返回最终结果 return { analysis: analysis, jira_creation_result: result_msg }至此我们完成了一个从非结构化反馈到自动创建Jira工单的完整、可驾驭的AI工作流。它具备了提示词工程、上下文检索、输出结构化校验、业务规则后处理以及工具调用等Harness Engineering的核心要素。4. 进阶思考从工作流到自主Agent的演进上面构建的是一个确定性的工作流。输入反馈经过一系列固定步骤输出结果。这在处理规则相对明确的任务时非常有效。但AI时代的终极想象是能处理开放目标、自主规划行动的Agent。我们如何向那个方向演进4.1 为工作流注入“决策”能力让我们升级之前的场景。用户反馈不再是简单的“卡顿”而可能是“我想让App在晚上自动进入勿扰模式并且只接收家人的消息。”这是一个功能请求而非问题报告。我们的系统需要识别意图这不是Bug是Feature Request。评估可行性检查现有App是否有类似功能技术实现难度如何规划行动是直接创建一个“新功能”工单还是先查询知识库看看有无类似需求是否需要先联系产品经理确认这需要我们将单一的链升级为一个由LLM驱动的决策路由器。# decision_router.py from langchain.schema import HumanMessage, SystemMessage class IntentRouter: def __init__(self, llm): self.llm llm def route(self, user_input: str) - dict: 判断用户输入的意图并决定下一步行动 system_prompt 你是一个需求分析助手。请分析用户的输入判断其属于以下哪种类型 1. BUG_REPORT: 报告应用错误、崩溃、性能问题。 2. FEATURE_REQUEST: 提出新的功能需求或改进建议。 3. GENERAL_QUESTION: 咨询如何使用某个功能或一般性问题。 4. OTHER: 其他无法归类的输入。 请以JSON格式输出包含两个字段 - intent: 上述类型之一。 - next_action: 建议的下一步处理动作。可选值 * classify_and_create_bug: 调用Bug分类流水线。 * evaluate_feature_request: 调用功能需求评估器。 * search_knowledge_base: 检索知识库并直接回复用户。 * human_help: 转接人工客服。 messages [ SystemMessage(contentsystem_prompt), HumanMessage(contentuser_input) ] response self.llm.invoke(messages) # 解析JSON响应此处省略解析代码 return parsed_response # 在主控流程中 router IntentRouter(llm) route_result router.route(user_feedback) if route_result[intent] BUG_REPORT: result full_feedback_pipeline(user_feedback) # 调用之前的Bug处理流水线 elif route_result[intent] FEATURE_REQUEST: result evaluate_feature_request(user_feedback) # 调用新的功能评估Agent elif route_result[intent] GENERAL_QUESTION: result search_and_answer(user_feedback) # 调用问答Agent else: result {action: forward_to_human, reason: 意图不明确}这样系统就具备了初步的“决策”能力可以根据输入内容动态选择执行路径。4.2 构建具备工具使用能力的评估Agent对于功能请求我们可以设计一个更复杂的Agent。它不仅能分类还能主动使用工具去调查。# feature_evaluator_agent.py from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain.memory import ConversationBufferMemory class FeatureEvaluator: def __init__(self, llm, jira_tool, doc_search_tool): self.llm llm # 定义Agent可以使用的工具 tools [ Tool( nameSearchSimilarRequests, funcdoc_search_tool.search_feature_requests, description在历史功能需求数据库中搜索类似的需求用于评估重复性和优先级。 ), Tool( nameCreateFeatureTicket, funcjira_tool.create_feature_issue, description在Jira中创建一个新的功能需求工单。输入应为工单的标题和详细描述。 ), Tool( nameEstimateComplexity, funcself.estimate_complexity_internal, # 一个内部函数调用另一个LLM或规则引擎进行粗略评估 description根据功能描述粗略评估其技术实现复杂度高/中/低。 ) ] # 给Agent一点记忆让它能记住对话上下文 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 初始化一个ReAct模式的Agent思考-行动循环 self.agent initialize_agent( tools, llm, agentAgentType.CHAT_CONVERSATIONAL_REACT_DESCRIPTION, # 适合多轮对话和工具使用 memorymemory, verboseTrue # 打开verbose可以看到Agent的思考过程调试用 ) def evaluate(self, feature_description: str): 评估一个功能需求 prompt f 你是一个产品技术评估员。请评估以下用户提出的功能需求 “{feature_description}” 你的任务是 1. 理解需求的本质。 2. 使用工具搜索是否有类似历史需求。 3. 评估其技术复杂度。 4. 综合判断这是一个全新的高价值需求还是一个重复的或低优先级的需求 5. 根据判断决定行动如果是高价值新需求创建Jira工单如果是重复需求告知用户并附上已有工单链接如果过于模糊请求用户澄清。 请开始你的工作一步步思考并使用合适的工具。 result self.agent.run(prompt) return result这个FeatureEvaluator就是一个初级Agent的雏形。它拥有目标评估功能需求。工具可以主动搜索、创建工单、评估复杂度。规划能力通过ReAct框架LLM会生成“Thought”思考下一步做什么、“Action”选择工具、“Observation”获取工具结果的循环直到达成目标或无法继续。注意事项Agent的可靠性挑战让Agent自主使用工具非常强大但也极其脆弱。你可能遇到工具选择错误Agent误解了工具描述调用了错误的工具。循环失控Agent陷入“思考-行动”的死循环无法得出结论。幻觉调用Agent可能生成一个不存在的工具名或参数。应对策略严格的工具描述为每个工具编写极其精确、无歧义的description这是Agent选择工具的唯一依据。设置最大步骤在初始化Agent时务必设置max_iterations或max_execution_time防止无限循环。后置验证对Agent的最终输出或关键行动如创建工单进行二次确认或加入人工审核环节。4.3 生存指南开发者如何在Agent时代定位自己当AI的能力从“执行命令”扩展到“自主规划”开发者的角色必然发生深刻变化。以下是我认为的几个关键定位1. 从“码农”到“产品架构师与规则制定者”你的核心工作不再是编写具体的for循环或API接口而是定义任务边界告诉Agent“做什么”目标而不是“怎么做”步骤。这需要极强的抽象和问题分解能力。设计交互协议制定Agent与工具、Agent与Agent、Agent与人之间的协作规则。就像设计一套公司内部的沟通流程。编写“世界规则”通过提示词、验证函数、业务规则库为Agent构建一个安全、可靠的行动边界。你是这个数字世界的“立法者”。2. 从“调试代码”到“调试认知”传统的Debug是检查变量值、逻辑分支。Agent时代的Debug是提示词调试为什么Agent误解了意图是提示词模糊还是缺少示例工具链调试为什么Agent总选错工具是工具描述不准还是检索的上下文不相关评估体系调试如何量化Agent任务完成的好坏需要设计新的评估指标如任务完成率、步骤效率、人工接管率。3. 成为“AI系统运维工程师”AI应用是“活”的需要持续喂养和观察。知识库运维定期更新RAG的源文档清理过时信息确保Agent的“记忆”准确。性能监控监控API延迟、Token消耗成本、任务成功率。设置警报当Agent的“反常”行为增多时如频繁调用某个失败工具及时介入。持续迭代收集失败案例分析根因不断优化提示词、工具集和流程编排。这是一个“训练-部署-监控-优化”的闭环。4. 保持你的“领域深度”与“批判性思维”这是你不可替代的护城河。Agent再强它也不真正理解你业务的细微差别、你用户的真实情感、你所在行业的潜规则。提供高质量种子你喂给Agent的示例、文档、规则决定了它的能力上限。你的领域知识就是最宝贵的训练数据。做最终的裁决者对于关键决策、创造性工作、涉及伦理或模糊地带的问题你必须保持最终控制权。AI是副驾驶你才是机长。培养“元”能力学习如何更有效地学习如何定义问题如何评估结果。这些能力能让你更好地驾驭AI而不是被替代。5. 常见陷阱与避坑指南在实践Harness Engineering和构建Agent的过程中我踩过不少坑。这里总结一份速查表希望能帮你绕开这些弯路。陷阱类别具体表现根本原因解决方案与避坑技巧提示词工程1. AI输出不稳定时好时坏。2. AI完全忽略指令中的关键约束。1. 提示词过于模糊或冗长。2. 关键指令被淹没在文本中。1.使用分隔符用###、tag等清晰分隔指令、上下文、示例。2.指令前置最重要的要求放在最前面。3.提供少量示例1-2个清晰的“Few-shot”示例效果远超千言万语。4.指定输出格式明确要求输出JSON、XML或特定标记文本。上下文管理1. RAG检索结果不相关导致AI“胡言乱语”。2. 上下文过长超出Token限制或导致AI注意力分散。1. 嵌入模型不适合领域或分块策略不佳。2. 无脑将所有检索结果拼接。1.领域微调嵌入模型如果资源允许用领域数据微调嵌入模型如bge系列。2.动态上下文压缩使用LLM本身来总结或提取检索到的文档中最相关的部分再喂给它。3.元数据过滤检索时加入时间、类型等过滤器。输出验证解析AI输出的JSON时频繁报错。AI没有严格遵守格式或输出包含额外解释文本。1.使用LangChain的StructuredOutputParser它会在提示词中自动加入格式指令并尝试修复小错误。2.设置后置清洗函数用正则表达式或简单规则提取JSON部分。3.“重试”机制如果解析失败将错误信息和原始输出再次发给AI要求它纠正。工具调用Agent错误调用工具或传入无效参数。工具的描述不够精确或Agent对参数理解有误。1.为工具编写“傻瓜式”描述假设使用者完全不懂。描述应包括精确功能、输入参数名称、类型、含义、示例、输出格式、可能发生的错误。2.参数验证前置在工具函数内部首先严格检查输入参数的类型和范围给出明确错误信息。3.使用TypeScript风格描述在Agent框架中用类似search(query: string, limit: number): PromiseArrayDocument的方式描述工具有助于AI理解。流程编排多步骤工作流在中间环节失败整个流程崩溃状态难以恢复。缺乏错误处理和状态持久化。1.每一步都幂等设计流程时尽量让每个步骤可重试且结果一致。2.记录中间状态使用数据库或消息队列记录每个步骤的输入、输出和状态成功/失败。3.实现补偿机制对于创建资源等操作要有对应的“回滚”或“清理”步骤。成本与延迟API调用费用飙升或用户等待时间过长。无节制地使用大模型或串联调用过多。1.任务路由简单任务分类、提取使用小模型或快模型如Haiku复杂任务推理、规划再用大模型如Sonnet、Opus。2.异步与流式对于长耗时任务采用异步处理先返回任务ID完成后通知。3.缓存对常见、结果确定的查询如“什么是XXX”结果进行缓存。最重要的心得不要试图一次性构建一个完美的、全能的Agent。从解决一个具体的、高价值的单点问题开始应用Harness Engineering的思想把它做扎实、做可靠。然后像搭积木一样将一个个可靠的“组件”连接起来逐步构建更复杂的能力。可靠性远比智能性更重要。一个99%时间都稳定工作的“笨”系统远胜于一个天马行空但10%时间会闯祸的“聪明”Agent。这条路还很长我们都在摸索。但可以肯定的是未来不属于那些只会手动提问的“Caveman”也不属于那些盲目崇拜AI、放弃思考的“魔法师”。它属于那些懂得如何为AI设计缰绳、规划路径、并与之协同共进的“驾驭者”。希望这篇手记能为你成为这样的驾驭者提供一块小小的垫脚石。