构建 Agent Harness：打造可靠 AI Agent 的核心控制层

Prompt Engineering、Context Engineering以及现在的 Harness Engineering。Prompt engineering 随着 2022 年底 ChatGPT 的发布进入公众视野定义了与大型语言模型高效交互的方式。Context engineering 则在去年2025 年走到台前构建者们尝试在上下文窗口限制内将尽可能多的有用信息塞进 prompt。Harness engineering 则成为今年的热点话题构建者优化模型周边的“脚手架”以确保 agent 能正确处理任务请求并尽可能给出最佳响应。LangChain https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering 探讨如何通过 harness engineering 改进 deep agents展示了在不更换底层模型的前提下通过调整 system prompts、tool 使用以及 middleware 来优化 agent 性能。尤其是中间的 middleware 层注入了目录上下文以加速 agent 上手、验证输出以进行质量校验并强制执行时间预算以在合理时限内完成工作。这表明agent 构建者不必一味等待下一个模型版本来提升质量而是可以“站在前沿实验室的肩膀上”取得更好的结果。Birgitta Böckeler 在一篇面向编码类 agent 用户的文章中提出了一个简单公式来定义 harness engineeringagent model harness。她这样阐述一个良好 harness 的目标一个构建良好的外部 harness 有两个目标它提高 agent 一开始“就做对”的概率并在结果到达人类视线之前提供尽可能多的问题自我纠正反馈回路。AWS 也刚刚为 AgentCore 推出 了全新的托管 agent harness用简单的基于配置的部署取代了前期繁琐的 agent 构建流程。在这篇博客中我将分享在我的 agent 平台原型 Loom 中构建 agent harness 的持续探索并介绍如何集成 AgentCore 的新 harness 作为另一种构建 agent 的选项。注为保证专业性与可对照性文中的专业名词如 agent harness、harness engineering、AgentCore、middleware、MCP、A2A、CLI、Bedrock、boto3、JWT、RFC 8693 等均保留英文原文必要处在首次出现时辅以中文解释。走进 Loom 的引擎盖之下在 Loom 的介绍文章中我提出了客户挑战 #4软件部署需要严格测试尤其是 AI 生成代码。因此我使用预写的 agent并通过 feature flags 启用 memory、tools、与其他 agents 的集成。这样既能进行标准化的代码扫描也无需为不受信任的代码执行准备隔离环境。通过配置注入构建预写的 agent为此我注入了一个名为AGENT_CONFIG_JSON的环境变量其负载如下{ system_prompt: persona, instructions, guidelines, model_id: us.amazon.nova-2-lite-v1:0, max_tokens: 16384, integrations: { mcp_servers: [ { name: utilities, enabled: true, transport: streamable_http, endpoint_url: https://example.heeki.cloud/mcp, auth: { type: oauth2, credential_provider_name: agentcore-credential-provider-for-utilities, well_known_endpoint: https://cognito-idp.region.amazonaws.com/cognito-pool-id/.well-known/openid-configuration, scopes: utilities/invoke ... } } ], a2a_agents: [ { name: agentforce-assistant, enabled: true, endpoint_url: https://api.salesforce.com/einstein/ai-agent/a2a/agent-identifier, auth: { type: oauth2, credential_provider_name: agentcore-credential-provider-for-agentforce-assistant, well_known_endpoint: https://organization-id.develop.my.salesforce.com/.well-known/openid-configuration } } ], memory: { enabled: true, resources: [ { name: demo_employee_assistant, memory_id: demo_employee_assistant-RNDrSHC2P5, arn: arn:aws:bedrock-agentcore:region:account-id:memory/demo_employee_assistant-RNDrSHC2P5 } ] } }}system_prompt参数将 persona、instructions、guidelines 这几项输入合并用于初始化 agent。agent Agent( system_promptconfig.system_prompt, modelmodel, toolstools, hookshooks,)model_id与max_tokens参数用于配置 Bedrock 模型。后续我计划扩展以支持其他 3p第三方模型提供方。model BedrockModel( model_idconfig.model_id, max_tokensconfig.max_tokens, streamingTrue,)integrations.mcp_servers与integrations.a2a_agents用于按条件定义 agent 的工具列表。下面的代码为了简洁做了轻微简化。if config.integrations.mcp_servers: enabled_servers [s for s in config.integrations.mcp_servers if s.enabled] if enabled_servers: mcp_clients build_mcp_clients(config.integrations.mcp_servers) tools.extend(mcp_clients) logger.info(Loaded %d MCP tool client(s), len(mcp_clients))if config.integrations.a2a_agents: enabled_agents [a for a in config.integrations.a2a_agents if a.enabled] if enabled_agents: a2a_clients create_a2a_clients(config.integrations.a2a_agents) if a2a_clients: tools.extend(a2a_clients) logger.info(Loaded %d A2A client(s), len(a2a_clients))integrations.memory参数用于决定是否在生命周期事件中接入与 memory 交互的 hook。if config.integrations.memory.enabled: memory_store_id None if config.integrations.memory.resources: memory_store_id config.integrations.memory.resources[0].memory_id memory_hook MemoryHook(memory_store_idmemory_store_id) hooks.append(memory_hook) logger.info(Enabled AgentCore Memory hook (store_id%s), memory_store_id)这种方式允许在部署时对 agent 进行配置并可根据具体用例的需要选择性地设置上述各项配置。但如果我想在运行时变更 agent 配置怎么办允许终端用户选择偏好的模型很常见在与 agent 交互途中追加工具集成也很常见。部署时配置 vs 运行时配置如何实现部署时配置作为默认设置运行时配置允许用户用自己的选择覆盖这些默认值。默认的部署配置与可在运行时覆盖的配置invoke 的负载支持在运行时覆盖模型、并新增 connectorstools 或其他 agents。这在InvokeRequest类中有定义。{ prompt: What is the weather in New York?, session_id: existing-session-id-or-null, model_id: us.amazon.nova-2-lite-v1:0, credential_id: 1, bearer_token: your-bearer-token, connector_ids: [3, 7]}prompt必填用户消息session_id复用现有会话省略则创建新会话model_id覆盖 agent 的默认模型必须在allowed_model_ids中credential_id用于令牌生成的内部授权方标识bearer_token手动生成的 bearer tokenconnector_ids本次调用要附加的内部 connector id例如我可以为某个 agent 配置一组可选模型终端用户只能从中选择。管理员视图为终端用户选择允许的模型然后终端用户即可选择自己的偏好模型。终端用户视图选择偏好模型如果用户选择了另一个模型该选择会随 invoke 请求一并传入随后 agent 会使用该模型进行处理。运行时添加工具在运行时更新模型相对容易因为这只是 agent 里多处理一个参数。而在运行时新增工具则有些“弯”需要格外注意。运行时启用 connector 的界面在介绍文中我提出了客户挑战 #6需要在委托的 actor 链条中管理身份传递。我建议用有意的架构约束将其简化为单跳。这也是许多 agent 式用户界面今天采取的方式——用户可按需启用连接。这种方式的关键好处在于当用户切换打开一个新的 connector 时顺势捕获用户凭证。我推测在这一刻采集凭证会带来“最小化”的用户授权疲劳因为用户此时强烈意图与该集成交互。等到真正需要时才去采集凭证并不合理因为用户可能已离开去处理一个长时任务。比如这就像你在 Claude Code 中启动了一个长时任务、转身离开回来后发现它在你离开 10 秒后就暂停执行了并请求你授权访问某个目录或读取某个文件。请注意这是一种“简化”而不是 agent 身份与权限委托问题的最终解。RFC 8693 是一个 token exchange 的提案它通过在 JWT 中携带 actor claim 的方式帮助进行委托。在上面的示例截图中我在 exa.ai/mcp 上注册并创建了一个 API key在免费档位下每月可发出 1000 次请求足以满足基础原型需求。虽然我可以在管理员层面配置 MCP server但这样做会导致每位启用该 connector 的用户都共用这把 API key。有的场景没问题但也有的场景需要“按用户”的 API key。MCP connectors 的按用户 API key我选择了后者。因此当用户启用该 connector 时会弹出一个对话框提示用户输入个人 API key。之后在请求 MCP server 时就使用这把个人 key。需要注意的是在我写下这段内容时AgentCore 的 credential providers 还不支持按用户的 API key。因此我是在 agent 请求里注入请求头而不是使用 credential provider。在 Loom 中集成托管的 agent harness为了达到目前的状态我进行了相当多的迭代。一方面自建 agent harness 让我学到了很多也带来了极大的灵活性比如为遥测与成本估算添加自定义日志。另一方面这可能比一个人愿意为 agent 平台投入的工程量更多。Harness for AgentCore 刚刚发布目标是简化 agent 的部署以及与各类上下文提供方的集成。我尤其喜欢托管 agent harness 的一点是它在部署时与运行时都同时支持模型选择与工具集成。比如在部署阶段我可以这样配置以 CLI 为例aws bedrock-agentcore-control create-harness \ --region us-east-1 \ --harness-name loom-harness-example \ --execution-role-arn arn:aws:iam::${ACCOUNT_ID}:role/loom-harness-role \ --system-prompt persona, instructions, guidelines \ --model us.amazon.nova-2-lite-v1:0 \ --max-iterations 75 \ --max-tokens 16384 \ --tools [{type: remote_mcp, name: exa, config: {remoteMcp: {url: https://mcp.exa.ai/mcp}}}] \ --memory {optionalValue: {agentCoreMemoryConfiguration: {arn: arn:aws:bedrock-agentcore:${REGION}:${ACCOUNT_ID}:memory/${MEMORY_ID}}}}同样地在运行时我也可以覆盖模型与工具选项例如response client.invoke_harness( harnessArnHARNESS_ARN, runtimeSessionIdSESSION_ID, messages[ { role: user, content: [ {text: Whats the weather in New York City?} ], } ], model{ bedrockModelConfig: { modelId: us.anthropic.claude-sonnet-4-6 } }, tools[ { type: remote_mcp, name: exa, config: {remoteMcp: {url: https://mcp.exa.ai/mcp}} } ])对于构建 agent 的全托管、serverless 体验而言这节省了大量时间而且部署过程相当轻快我的自定义 agent 大约需要 1 分钟harness 部署只需约 20 秒在 Loom 中使用 AgentCore 新 harness 创建的 agent我也已经将托管的 agent harness 集成进 Loom并在版本 1.3.0 中提供。请注意你需要将boto3升级到1.42.94版本以使用新的 harness 方法。另请注意对于需要 OAuth2 access tokens 的远程 MCP servers目前似乎还不支持 credential providers需要自行添加自定义授权请求头。{ harnessArn: arn:aws:bedrock-agentcore:region:account-id:harness/harness-id, runtimeSessionId: 552bb0ed-f268-46e6-9db9-53df37b149f0, messages: [ { role: user, content: [ { text: Whats the weather in New York City? } ] } ], tools: [ { type: remote_mcp, name: utilities, config: { remoteMcp: { url: https://mcp-server-endpoint/mcp, headers: { Authorization: Bearer } } } } ], actorId: admin}结语随着各组织同时追求效率与响应质量harness engineering 正当其时。构建一个 agent harness 并非难事但确实需要仔细权衡与设计。AWS 刚刚发布了全托管的 agent harness显著简化了在云端构建与部署 agent 的体验。AWS 控制台还提供了 playground 体验让测试变得非常轻松。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】