1. 为什么需要一支专门的Harness Engineering团队先从一个很现实的场景说起：你所在的创业团队花三个月做出了一个基于大模型的Agent产品Demo，演示给投资人看时效果炸裂，但真正进入客户试用阶段，问题接踵而来——模型给出正确意图却在调用工具时频繁失败、上下文管理混乱导致多轮对话总是丢失信息、同一个用户提问，上一次回复表现优秀这一次却答非所问。此时你才发现，Demo跑通和生产可用之间，隔着一层几乎没人愿意主动承担的工程脏活。这层脏活，就是AI Agent领域的Harness Engineering。先解释一下这个术语。Harness直译是"马具、缰绳"，放在Agent工程语境里，指的是把模型能力"约束"到可控生产状态的那整套中间层系统。具体包括Prompt编排与管理、结构化输出解析、工具函数调用框架、工作流状态机、上下文窗口的压缩与检索策略、记忆读写机制、模型行为评测体系，以及运行时的监控与兜底降级逻辑。没有这些，Agent就只是一个"看起来聪明但完全不可信"的玩具；有了这些，它才勉强称得上一个能交给客户的产品。在组建团队这件事上，很多创始人的第一反应是"既然这么重要，那就多招几个算法工程师"。这是最容易犯的错误。Harness Engineering团队的核心并不只是做模型侧的研究，而是在模型能力边界之内构建产品化的控制框架。它的人才画像应当是"既懂模型行为逻辑、又具备系统化工程思维"的混合型工程师，加上能把模糊的用户需求翻译成技术任务的产品角色，以及能理解开发者生态的市场角色。这篇文章想聊的，就是在AI Agent创业公司（尤其是处于Pre-A到A轮这个阶段）里，怎么把这支团队的配置方案做出来：人员画像怎么定义、比例怎么分配、三拨人之间该用什么样的协作机制才能不互相拖后腿、以及真实招聘和落地过程中有哪些坑是文档里不会写的。我自己参与过两个类似的创业团队组建工作，从零到十几人规模的痛苦、试错和最终的跑通都经历过，所以下面这些内容既有方案本身，也有方案背后的取舍逻辑，希望能帮准备搭这类团队的人少走一点弯路。2. 技术岗配置：控制层、数据层与质量层的三角结构2.1 谁才是Harness Engineering的核心工程师技术侧是这支团队的骨架，但骨架不等于人越多越好。在创始团队时期，真正需要优先找的不是十项全能的全栈天才，而是三类边界清晰的人：控制层工程师、数据层工程师、质量层工程师。如果预算只允许你先招三个人，我会建议按这个顺序来。控制层工程师负责的是"Agent行为可控"的核心工程，包括Prompt编排框架、函数调用的路由与纠错机制、状态机设计、工具执行的并发与超时控制。这个岗位的工作内容看起来像后端工程师在做的事，但他必须额外具备一个能力：理解大模型输出的概率性和突发性。举个例子，工具调用的入参校验看起来是写几百行JSON Schema，但真正难的是当模型输出了一个合法的但是语义完全错误的参数时，系统能不能够在上游捕获这个错误并提供给模型一次自纠机会。这种设计需要工程师对模型行为有直觉。数据层工程师则负责记忆、上下文和检索相关的数据管道。多轮Agent对话里最常见的翻车原因不是模型不够聪明，而是上下文窗口被无关信息填满，关键信息被挤掉。数据层工程师要设计的是"该把什么放进上下文、该把什么压缩存储、哪些信息要进向量库做快速召回"这整套逻辑。他在团队里的角色相当于Agent的"记忆管理者"。质量层工程师是很多创业团队最容易忽略的一个角色。他的核心任务是搭评测体系：设计回归测试集、搭建离线评测流程、定义各类Agent任务的成功率与失败模式、把评测结果沉淀成可视化看板。没有这个角色，控制层工程师做的优化就永远是"感觉好了点"而无法被量化验证，产品团队也无法在版本迭代时判断"这次改动到底是提升了还是退化了Agent表现"。2.2 初期配比：宁可少而精，不要结构化超标很多创始人一上来就按大厂的中台逻辑配人：控制层两个，数据层两个，质量层两个，再配三个后端支持。这个配比放到十几个人规模时会直接拖垮公司——因为效率核心在于信息同步，而人一多，同步成本呈指数上升。我建议起步阶段（总技术人数在6到8人之间）采用2:1:1的控制层、数据层、质量层配比，让每个质量层工程师同时肩上扛着部分数据管道的工作，这样能保持足够精简。等到做商业化验证、客户定制化需求变多以后，再把数据层和质量层扩编到2:2，控制层保持不变。原因在于，当Agent产品进入客户环境，异构数据源和多样性任务需求会大量涌入，数据管道和评测体系这两个最需要"堆工作量"的环节会先出现瓶颈，而控制层核心框架一旦稳定，它的改动频率反而会降低。此时保持控制层人员的稳定是架构上的最优解——他们连续拥有最完整的系统上下文，让重构成本降到最低。2.3 技术岗面试里必须考察的三个隐藏维度常规的技术面试只能验证候选人的编码能力和算法功底，但对Harness Engineering团队来说，有三个维度必须在面试中专门考察，否则进来后大概率出问题。第一个是模型行为意识。我会在面试中直接问一个问题：如果同一个Prompt在两次调用中得到完全不同的输出，你的第一反应是什么？只会回答"重试一次"的候选人是没有模型行为意识的，而具备这种意识的人会先想到"是温度参数没固定，还是上下文里的隐式状态变了，还是模型版本被自动流转了"。后者才是生产环境里真正需要的排查思路。第二个是失败模式设计能力，尤其是对"失败优先级"的判断。可以出一个情境题：一个Agent在调用支付工具时出现超时，系统应该向用户展示什么信息？错误提示模板应该怎么设计？这个题没有绝对正确或错误的答案，但有效的候选人会想到"目前尚不能确定支付是否成功"和"支付失败"这两句提示在用户安全感上的含义完全不同，并且在系统设计上会针对不确定性专门设计提示文案。这就是做Agent产品时最需要的思维层次。第三个是跨模块沟通意愿。Harness工程师不可能只跟代码打交道，他需要频繁与产品接口人核对用户场景、跟市场同事确认演示环境的限制。面试时观察候选人在描述技术方案时是否愿意提"这个功能需要产品侧配合UI文案""这里最好让市场同事确认客户预期"这类表述，比看他写了几年代码更说明问题。3. 产品岗配置：Agent产品的核心是"交互设计与模型输出的共同设计"3.1 这个产品岗不是画原型图的人传统SaaS产品经理的核心技能是用户研究、场景拆解、功能排期和原型设计。但Agent产品的产品岗有一个截然不同的特征：他设计的不仅是用户界面，更是模型的行为边界和用户的预期管理。换句话说，这个产品经理必须同时理解"模型能做什么"和"用户会怎么以为它能做什么"，然后再把两者之间那个缺口用产品手段堵上。举例来说，当用户在对话里要求Agent完成"帮我查一下上周所有未支付的订单然后批量发送催款"时，模型大概率会执行，但用户并没有告诉它催款语气是温和还是强硬。这个决策如果交给模型自由发挥，结果不可控。产品经理需要做的就是设计出这样一段交互：在首次表达批量催款意图时，Agent主动追问一次语气偏好，然后记住这个偏好并在后续批量执行中沿用。类似这种"在信息不对称时主动补全决策参数"的交互设计，就是Agent产品的产品岗最值钱的能力。这个能力不是看几篇产品方法论文章能获得的，它要求产品经理能够实际上手测试模型在不同Prompt和不同参数下的行为差异，并且在设计过程中把模型的输出格式、工具调用参数一并纳入产品规格的定义。3.2 产品岗还需要具备"过程可视化"的设计功力传统软件设计的是功能，Agent产品设计的是"过程"。因为Agent执行一个复杂任务时，内部会经历多轮思考和工具调用，用户面对的是一个黑盒——在黑盒里执行时间越长，用户的不确定感就越强。优秀的产品经理会把每个关键步骤设计成用户可感知的中转站。举一个实际例子：一个文档处理Agent在处理一份五十页的合同时，它需要先读取全文、识别关键条款、再逐条比对风险点。全程可能需要一两分钟。如果界面一直显示"努力处理中"，用户大概率会在三十秒内怀疑系统卡死。产品方案里应该拆出三个阶段——"正在读取合同结构""已识别关键条款12条""正在逐条比对风险"，每个阶段配对应的小进度提示。这个设计并不复杂，但恰恰非常关键——它解决的是AI产品特有的"不确定性焦虑"。这要求产品经理对模型执行过程有精确感知，而不是只会在PRD里画线框图。3.3 一个合格Agent产品负责人的MVP验证题招产品岗时我建议不看作品集里那些漂亮的原型图，给他一个实际的小任务：用现成的Agent开发平台搭一个"自动整理会议纪要并提取待办事项"的Agent，要求他独立完成流程拆解、Prompt设计和评测指标定义，最后展示结果并讲解设计取舍。这个任务不会花超过几个小时，但它能一口气考察三件事：候选项是否愿意动手触碰真实模型（很多只会画图的产品经理在这一步就露馅了）、在模型输出不如意时能否快速调整方案，以及能否为自己的设计定义出可衡量的成功标准。做完这个任务后还需要追问一轮：如果模型在"提取待办事项"这个环节的准确率只有百分之八十，你会怎么设计产品逻辑来兜底？这个问题的分水岭在于，合格的产品负责人会想到"利用二次确认交互把低置信度的抽取结果展示出来让用户审核修正"，而能力不足的候选人只会说"我们换一个更强的模型来解决"，后者在创业团队里是无法打硬仗的。4. 市场岗配置：理解开发者生态比做品牌投放重要一百倍4.1 市场角色在创业早期的正确打开方式当一个创业团队做的是面向开发者的Agent Harness工具或平台时，传统的市场营销方法论几乎全部失效。没有人会因为投了一篇品牌软文而决定把核心业务链路搭在你们的Agent框架上，开发者决策靠的是口碑、开源社区讨论和动手体验三件事。所以市场岗的头号任务是——创造开发者愿意主动尝试的内部机会，而不是去铺渠道做广告。这个岗位的画像应该是有开发者关系或技术社区运营经验的人，他自己不一定要会写代码，但必须懂开发者群体的语言习惯和信息获取路径。他要做的第一件事是在技术社区里建立存在感：输出高质量的Agent工程实践文章、在开源项目仓库里维护一份真正有用的文档、组织线上线下的小型Workshop，让目标用户在实际操作中感受到产品的价值。4.2 市场岗的考核指标不能是空泛的"品牌声量"我见过很多创业公司在市场岗的考核KPI里写"全网曝光量""公众号涨粉量"，这放在Agent工具的早期市场阶段基本是无效指标。正确的做法是围绕三个阶段设定递进式指标：早期阶段（产品尚未发布）考核的是种子用户列表——有多少目标开发者留下了联系方式、表示愿意测试产品。这里的核心动作是把市场工作前置到产品开发阶段，让市场人员参与早期技术方向的讨论，收集潜在用户的真实诉求反馈给产品团队。中期阶段（产品可测试）考核激活率——拿到测试资格的开发者中有多少真正完成了环境部署并跑通了Demo。这个指标直接检验文档质量和上手体验，也是技术团队最该关心的外部反馈。后期阶段（商业验证）考核的是社区自传播率——有多少用户主动把产品推荐给了同事或写进了自己的技术博客。这三类指标有一个共同点：它们逼着市场人员与技术和产品团队紧密协作，而不是单打独斗做"对外发声"。如果市场岗进来的第一反应是"给我预算买量做投放"，说明他还没有理解这个行业。4.3 市场、产品、技术三方的信息流设计市场侧在很多创业团队里是信息孤岛，因为大家默认"市场是对外的事"。但在Agent工具这个领域，市场人员恰恰是最早接触真实用户反馈的人——他在社区里回答问题、在某一场Workshop里收集到参会者的吐槽，这些信息如果只是沉淀在市场的表格里，价值就打了对折。我比较推荐的机制是：市场岗每周提交一份"用户声音周报"，里面按三个优先级分类——影响Demo验证的阻断问题、影响功能预期的认知偏差、以及潜在的商业化线索。这份周报不是发给CEO做汇报用的，而是直接推给产品和技术负责人作为下一轮迭代的输入。与之对应的，技术侧的版本更新说明也必须由市场岗参与撰写，确保专业术语被翻译成用户能感知的"能力提升"或者"问题修复"，而不是一堆commit message的堆砌。5. 创业环境下的招聘渠道与评估实操5.1 不要只盯着常规招聘平台技术岗位通过常规招聘渠道招到优质候选人的概率不高，尤其是在Harness Engineering还比较新兴的背景下。我身边跑通的做法有这么几个方向：一是在技术社区发布高质量的内容吸引被动求职者——很多优秀工程师不会主动投简历，但会因为在社区里看到你写的工程方案解析而产生兴趣，这时候一篇带有团队真实技术选型和踩坑记录的文章，比一个写得再好的招聘帖都有吸引力；二是对已有Agent开源生态的贡献者发起定向邀请，因为这些贡献者已经在实践中证明了自己对这个领域的热情和动手能力，而不是仅仅停留在会说概念的阶段；三是创业团队之间的"交叉引荐"，同行虽然存在竞争，但彼此也在相互关注，推荐过来的人常常是最靠谱的。5.2 三份评估表单，怎么看候选人而不是"感觉他很强"经常有创始人问我，面试的时候感觉候选人什么都答得上，但要做出判断就是没有抓手。这里分享一套实操下来效果不错的评估框架，分别对应技术、产品、市场三个岗位。技术岗的评估表有五个维度：模型行为意识、系统设计能力、失败排查思路、代码质量、沟通简洁度。每个维度按1到5分打分，但特别要注意的是——前两个维度的分数必须拉满才值得进入下一轮，后面三项哪怕普通一些也可以接受，因为这些能力可以在团队内部通过协作来弥补。产品岗的评估表则是另一个侧重点：场景拆解能力、交互设计中的不确定性处理、动手实测意愿、指标定义能力。其中"动手实测意愿"是很难培养的，缺乏这个特质的产品经理即使其他方面再优秀，放到Agent产品岗位上也会很别扭。市场岗的评估相对独特，关键维度包括：对开发者社区的理解深度、内容输出能力、技术方案的理解转化能力、以及数据敏感度。现实中很多市场岗候选人会在"内容输出能力"上失分——他可能做过大量传统营销活动，却从来没有写过一篇能被技术论坛认可的技术实践类文章。每轮面试结束后，当场做一次完整的打分并写一句"印象记忆点"，别拖到全部面试完再补。这不是走流程，而是防止你的判断被最后一件小事主导，这是我在实践中经常踩到的坑。5.3 创业团队的薪酬与激励：现金期权怎么分配才不埋雷预算有限是创业团队的常态，所以钱要花在刀刃上。给予核心的Harness工程师略低于市场水平的现金薪酬，但配给足够多的期权是常见做法，这个前提是对方真的认可方向。这里想特别提醒的是，技术团队里不要在期权分配上搞平均主义。控制层核心工程师拿到的期权比例最好是同级别普通工程师的1.8到2倍，因为他在系统积累上的不可替代性最强。而产品岗和市场岗因为决策可以相对频繁地调整，期权的集中度就不需要那么极端，但也要保证他的总回报预期在认可行业风险的前提下是可接受的。还有一个经常被忽略的点：现金薪酬的差距不要拉得过大。如果市场岗的现金收入比技术岗少非常多，跨岗位协作的时候会天然产生心理层级，造成"技术说什么产品只能执行"，这对Agent产品这种需要深度协同的团队是致命的。合理的结构是现金有梯度但不悬殊，期权拉开差距体现核心价值，两者叠加以后，让每个人都感觉自己拿到了一个公平的"总包"。6. 三拨人怎么共事：避免团队组建后的结构性内耗6.1 需求流：用"场景卡片"取代长篇PRD我对产品团队有一个硬性要求：所有新功能的需求描述，最终都要压缩成一张结构清晰的场景卡片，而不是几十页的PRD文档。场景卡片只有四个字段——目标用户与触发场景、用户当前遇到的阻碍、Agent需要执行的动作链路、成功标准与验收指标。这里不是要求每个卡片里的信息都要完整详尽，而是用统一的格式把决策成本降到最低。为什么这样做？因为Agent产品的开发过程高度依赖产品与技术之间的快速对齐。工程师拿到传统PRD后，通常需要花大量时间自行理解场景再翻译成系统逻辑，这个环节的信息损耗往往极大。而一张场景卡片能让技术同事用最短时间判断"这个需求应该落在Prompt层、工具函数层，还是UI交互层"，在会议中就能给出排期评估。我在A团队的实验表明，实施场景卡片之后，需求从提出到进入开发的周期压缩了将近一半。这不是什么魔法，只是消除了信息翻译过程中那些来回确认的等待时间。6.2 技术流：评测看板必须成为所有人开会依赖的数据底座当一个团队同时有技术、产品和市场三条线时，语言体系天然分裂：技术谈架构，产品谈交互，市场谈用户反馈，而Agent产品的质量本质上是一个跨三者的复合命题。把这三者串起来的关键，是评测看板——一套由质量层工程师维护、所有角色都会打开看的数据面板。看板上至少要有这几个维度：核心任务成功率（如"正确完成工具调用并生成最终答案"）、工具调用失败的首要原因归类（模型参数错误、超时、工具本身Bug）、各场景平均轮次和耗时、以及多轮对话中的信息遗忘率。产品经理在需求评审时用这些数据论证优先级，技术负责人在迭代规划时用它们衡量优化效果，市场同事在与客户沟通时把它们变成产品能力的客观素材。每周固定一次"评测会"——不是正式述职，而是所有人对着看板聊"这个失败率为什么反弹了"。这个习惯一旦养成，团队共识就自然形成，三拨人不会再各说各话。6.3 冲突流：当产品和技术对"模型能力边界"的判断不一致时这种冲突在Agent团队里的发生频率远高于传统软件团队。典型场景是：产品希望Agent能在一次对话里完成"解析合同->提取风险条款->生成修订建议"三个环节，技术评估后认为当前模型的上下文处理能力无法稳定支撑，但产品认为用户需求就应该被完整满足，不能拆成三步割裂的对话。过去处理这类分歧时，大家通常会议论"谁的判断更准确"。事实上在早期阶段，模型的真实能力边界本身就是一个动态变化的对象，产品和技术各自都只有部分信息。更务实的办法是用一个分层妥协方案来推进：第一层由系统预设一个可以覆盖全流程的Prompt框架，第二层在每一步工具调用后加入上下文摘要环节来做记忆压缩，第三层在UI上提供"分阶段执行"的降级选项，让用户选择是自动串联还是逐步确认。大多数这类分歧都能在这个三层机制里找到共同落点，实在找不到再上升讨论范围，而不是停留在"谁对谁错"的意气之争上。7. 关于初创团队组建的最终几点体会回想我带过和旁观过的几个Agent创业团队，一个很深的感触是：技术、产品、市场这三类人之间的摩擦，本质上是视角的摩擦，而不是人的摩擦。技术人看到的Agent是一个概率系统，产品人看到的是用户信任，市场人看到的是行业风口，三方都没有错，但如果没有人把这三种视角拧成一股绳，团队就会散成一盘棋。我自己在实操中的几条经验，最后分享在这里：第一，把评测体系当作团队组建后的第一个共同交付物。技术、产品、市场三个角色只有围绕同一套数据建立共识，协作才会变得顺滑。技术通过它证明优化有效，产品通过它建立迭代节奏，市场通过它对外讲故事，三方都受益于这套底座。第二，早期宁可让产品经理多动手碰模型，也不要让他只做需求翻译和排期。Agent产品经理的直觉是在一次次的实测中养成的，这种直觉是任何规模、任何级别的团队协作都替代不了的。如果产品经理从头到尾不实际运行一次Agent，他设计的每一个交互方案都是在隔靴搔痒。第三，市场角色不要被锁死在"对外发声"，他在团队内部的信息枢纽意义往往比创造的外部传播价值更大。把用户声音通过他系统性地回流到技术与产品侧，整个团队的迭代方向才会更贴近真实需求，少走很多自嗨的弯路。最后再讲一个实用的技巧：在新成员加入的头三十天，让他独立负责一个完整的端到端小任务，技术岗就让他搭一个从Prompt到评测的完整闭环，产品岗就让他把某一个场景从卡片推进到上线，市场岗就让他独立发起一场社区活动并收集回访数据。这个"首月闭环"的做法比任何入职培训都更能检验一个候选人的真实成色，同时也能让团队在非常短的时间里看到新成员的思考方式和行为惯性，尽早发现匹配度问题。AI Agent Harness Engineering的创业窗口期还很长，但窗口期的红利属于那些能快速把队伍拉起来、把协作跑顺、把产品扎进真实场景的团队。希望这篇关于人才配置的复盘，能帮你少一些我在组建过程中走过的弯路。
1. 为什么需要一支专门的Harness Engineering团队先从一个很现实的场景说起：你所在的创业团队花三个月做出了一个基于大模型的Agent产品Demo，演示给投资人看时效果炸裂，但真正进入客户试用阶段，问题接踵而来——模型给出正确意图却在调用工具时频繁失败、上下文管理混乱导致多轮对话总是丢失信息、同一个用户提问，上一次回复表现优秀这一次却答非所问。此时你才发现，Demo跑通和生产可用之间，隔着一层几乎没人愿意主动承担的工程脏活。这层脏活，就是AI Agent领域的Harness Engineering。先解释一下这个术语。Harness直译是"马具、缰绳"，放在Agent工程语境里，指的是把模型能力"约束"到可控生产状态的那整套中间层系统。具体包括Prompt编排与管理、结构化输出解析、工具函数调用框架、工作流状态机、上下文窗口的压缩与检索策略、记忆读写机制、模型行为评测体系，以及运行时的监控与兜底降级逻辑。没有这些，Agent就只是一个"看起来聪明但完全不可信"的玩具；有了这些，它才勉强称得上一个能交给客户的产品。在组建团队这件事上，很多创始人的第一反应是"既然这么重要，那就多招几个算法工程师"。这是最容易犯的错误。Harness Engineering团队的核心并不只是做模型侧的研究，而是在模型能力边界之内构建产品化的控制框架。它的人才画像应当是"既懂模型行为逻辑、又具备系统化工程思维"的混合型工程师，加上能把模糊的用户需求翻译成技术任务的产品角色，以及能理解开发者生态的市场角色。这篇文章想聊的，就是在AI Agent创业公司（尤其是处于Pre-A到A轮这个阶段）里，怎么把这支团队的配置方案做出来：人员画像怎么定义、比例怎么分配、三拨人之间该用什么样的协作机制才能不互相拖后腿、以及真实招聘和落地过程中有哪些坑是文档里不会写的。我自己参与过两个类似的创业团队组建工作，从零到十几人规模的痛苦、试错和最终的跑通都经历过，所以下面这些内容既有方案本身，也有方案背后的取舍逻辑，希望能帮准备搭这类团队的人少走一点弯路。2. 技术岗配置：控制层、数据层与质量层的三角结构2.1 谁才是Harness Engineering的核心工程师技术侧是这支团队的骨架，但骨架不等于人越多越好。在创始团队时期，真正需要优先找的不是十项全能的全栈天才，而是三类边界清晰的人：控制层工程师、数据层工程师、质量层工程师。如果预算只允许你先招三个人，我会建议按这个顺序来。控制层工程师负责的是"Agent行为可控"的核心工程，包括Prompt编排框架、函数调用的路由与纠错机制、状态机设计、工具执行的并发与超时控制。这个岗位的工作内容看起来像后端工程师在做的事，但他必须额外具备一个能力：理解大模型输出的概率性和突发性。举个例子，工具调用的入参校验看起来是写几百行JSON Schema，但真正难的是当模型输出了一个合法的但是语义完全错误的参数时，系统能不能够在上游捕获这个错误并提供给模型一次自纠机会。这种设计需要工程师对模型行为有直觉。数据层工程师则负责记忆、上下文和检索相关的数据管道。多轮Agent对话里最常见的翻车原因不是模型不够聪明，而是上下文窗口被无关信息填满，关键信息被挤掉。数据层工程师要设计的是"该把什么放进上下文、该把什么压缩存储、哪些信息要进向量库做快速召回"这整套逻辑。他在团队里的角色相当于Agent的"记忆管理者"。质量层工程师是很多创业团队最容易忽略的一个角色。他的核心任务是搭评测体系：设计回归测试集、搭建离线评测流程、定义各类Agent任务的成功率与失败模式、把评测结果沉淀成可视化看板。没有这个角色，控制层工程师做的优化就永远是"感觉好了点"而无法被量化验证，产品团队也无法在版本迭代时判断"这次改动到底是提升了还是退化了Agent表现"。2.2 初期配比：宁可少而精，不要结构化超标很多创始人一上来就按大厂的中台逻辑配人：控制层两个，数据层两个，质量层两个，再配三个后端支持。这个配比放到十几个人规模时会直接拖垮公司——因为效率核心在于信息同步，而人一多，同步成本呈指数上升。我建议起步阶段（总技术人数在6到8人之间）采用2:1:1的控制层、数据层、质量层配比，让每个质量层工程师同时肩上扛着部分数据管道的工作，这样能保持足够精简。等到做商业化验证、客户定制化需求变多以后，再把数据层和质量层扩编到2:2，控制层保持不变。原因在于，当Agent产品进入客户环境，异构数据源和多样性任务需求会大量涌入，数据管道和评测体系这两个最需要"堆工作量"的环节会先出现瓶颈，而控制层核心框架一旦稳定，它的改动频率反而会降低。此时保持控制层人员的稳定是架构上的最优解——他们连续拥有最完整的系统上下文，让重构成本降到最低。2.3 技术岗面试里必须考察的三个隐藏维度常规的技术面试只能验证候选人的编码能力和算法功底，但对Harness Engineering团队来说，有三个维度必须在面试中专门考察，否则进来后大概率出问题。第一个是模型行为意识。我会在面试中直接问一个问题：如果同一个Prompt在两次调用中得到完全不同的输出，你的第一反应是什么？只会回答"重试一次"的候选人是没有模型行为意识的，而具备这种意识的人会先想到"是温度参数没固定，还是上下文里的隐式状态变了，还是模型版本被自动流转了"。后者才是生产环境里真正需要的排查思路。第二个是失败模式设计能力，尤其是对"失败优先级"的判断。可以出一个情境题：一个Agent在调用支付工具时出现超时，系统应该向用户展示什么信息？错误提示模板应该怎么设计？这个题没有绝对正确或错误的答案，但有效的候选人会想到"目前尚不能确定支付是否成功"和"支付失败"这两句提示在用户安全感上的含义完全不同，并且在系统设计上会针对不确定性专门设计提示文案。这就是做Agent产品时最需要的思维层次。第三个是跨模块沟通意愿。Harness工程师不可能只跟代码打交道，他需要频繁与产品接口人核对用户场景、跟市场同事确认演示环境的限制。面试时观察候选人在描述技术方案时是否愿意提"这个功能需要产品侧配合UI文案""这里最好让市场同事确认客户预期"这类表述，比看他写了几年代码更说明问题。3. 产品岗配置：Agent产品的核心是"交互设计与模型输出的共同设计"3.1 这个产品岗不是画原型图的人传统SaaS产品经理的核心技能是用户研究、场景拆解、功能排期和原型设计。但Agent产品的产品岗有一个截然不同的特征：他设计的不仅是用户界面，更是模型的行为边界和用户的预期管理。换句话说，这个产品经理必须同时理解"模型能做什么"和"用户会怎么以为它能做什么"，然后再把两者之间那个缺口用产品手段堵上。举例来说，当用户在对话里要求Agent完成"帮我查一下上周所有未支付的订单然后批量发送催款"时，模型大概率会执行，但用户并没有告诉它催款语气是温和还是强硬。这个决策如果交给模型自由发挥，结果不可控。产品经理需要做的就是设计出这样一段交互：在首次表达批量催款意图时，Agent主动追问一次语气偏好，然后记住这个偏好并在后续批量执行中沿用。类似这种"在信息不对称时主动补全决策参数"的交互设计，就是Agent产品的产品岗最值钱的能力。这个能力不是看几篇产品方法论文章能获得的，它要求产品经理能够实际上手测试模型在不同Prompt和不同参数下的行为差异，并且在设计过程中把模型的输出格式、工具调用参数一并纳入产品规格的定义。3.2 产品岗还需要具备"过程可视化"的设计功力传统软件设计的是功能，Agent产品设计的是"过程"。因为Agent执行一个复杂任务时，内部会经历多轮思考和工具调用，用户面对的是一个黑盒——在黑盒里执行时间越长，用户的不确定感就越强。优秀的产品经理会把每个关键步骤设计成用户可感知的中转站。举一个实际例子：一个文档处理Agent在处理一份五十页的合同时，它需要先读取全文、识别关键条款、再逐条比对风险点。全程可能需要一两分钟。如果界面一直显示"努力处理中"，用户大概率会在三十秒内怀疑系统卡死。产品方案里应该拆出三个阶段——"正在读取合同结构""已识别关键条款12条""正在逐条比对风险"，每个阶段配对应的小进度提示。这个设计并不复杂，但恰恰非常关键——它解决的是AI产品特有的"不确定性焦虑"。这要求产品经理对模型执行过程有精确感知，而不是只会在PRD里画线框图。3.3 一个合格Agent产品负责人的MVP验证题招产品岗时我建议不看作品集里那些漂亮的原型图，给他一个实际的小任务：用现成的Agent开发平台搭一个"自动整理会议纪要并提取待办事项"的Agent，要求他独立完成流程拆解、Prompt设计和评测指标定义，最后展示结果并讲解设计取舍。这个任务不会花超过几个小时，但它能一口气考察三件事：候选项是否愿意动手触碰真实模型（很多只会画图的产品经理在这一步就露馅了）、在模型输出不如意时能否快速调整方案，以及能否为自己的设计定义出可衡量的成功标准。做完这个任务后还需要追问一轮：如果模型在"提取待办事项"这个环节的准确率只有百分之八十，你会怎么设计产品逻辑来兜底？这个问题的分水岭在于，合格的产品负责人会想到"利用二次确认交互把低置信度的抽取结果展示出来让用户审核修正"，而能力不足的候选人只会说"我们换一个更强的模型来解决"，后者在创业团队里是无法打硬仗的。4. 市场岗配置：理解开发者生态比做品牌投放重要一百倍4.1 市场角色在创业早期的正确打开方式当一个创业团队做的是面向开发者的Agent Harness工具或平台时，传统的市场营销方法论几乎全部失效。没有人会因为投了一篇品牌软文而决定把核心业务链路搭在你们的Agent框架上，开发者决策靠的是口碑、开源社区讨论和动手体验三件事。所以市场岗的头号任务是——创造开发者愿意主动尝试的内部机会，而不是去铺渠道做广告。这个岗位的画像应该是有开发者关系或技术社区运营经验的人，他自己不一定要会写代码，但必须懂开发者群体的语言习惯和信息获取路径。他要做的第一件事是在技术社区里建立存在感：输出高质量的Agent工程实践文章、在开源项目仓库里维护一份真正有用的文档、组织线上线下的小型Workshop，让目标用户在实际操作中感受到产品的价值。4.2 市场岗的考核指标不能是空泛的"品牌声量"我见过很多创业公司在市场岗的考核KPI里写"全网曝光量""公众号涨粉量"，这放在Agent工具的早期市场阶段基本是无效指标。正确的做法是围绕三个阶段设定递进式指标：早期阶段（产品尚未发布）考核的是种子用户列表——有多少目标开发者留下了联系方式、表示愿意测试产品。这里的核心动作是把市场工作前置到产品开发阶段，让市场人员参与早期技术方向的讨论，收集潜在用户的真实诉求反馈给产品团队。中期阶段（产品可测试）考核激活率——拿到测试资格的开发者中有多少真正完成了环境部署并跑通了Demo。这个指标直接检验文档质量和上手体验，也是技术团队最该关心的外部反馈。后期阶段（商业验证）考核的是社区自传播率——有多少用户主动把产品推荐给了同事或写进了自己的技术博客。这三类指标有一个共同点：它们逼着市场人员与技术和产品团队紧密协作，而不是单打独斗做"对外发声"。如果市场岗进来的第一反应是"给我预算买量做投放"，说明他还没有理解这个行业。4.3 市场、产品、技术三方的信息流设计市场侧在很多创业团队里是信息孤岛，因为大家默认"市场是对外的事"。但在Agent工具这个领域，市场人员恰恰是最早接触真实用户反馈的人——他在社区里回答问题、在某一场Workshop里收集到参会者的吐槽，这些信息如果只是沉淀在市场的表格里，价值就打了对折。我比较推荐的机制是：市场岗每周提交一份"用户声音周报"，里面按三个优先级分类——影响Demo验证的阻断问题、影响功能预期的认知偏差、以及潜在的商业化线索。这份周报不是发给CEO做汇报用的，而是直接推给产品和技术负责人作为下一轮迭代的输入。与之对应的，技术侧的版本更新说明也必须由市场岗参与撰写，确保专业术语被翻译成用户能感知的"能力提升"或者"问题修复"，而不是一堆commit message的堆砌。5. 创业环境下的招聘渠道与评估实操5.1 不要只盯着常规招聘平台技术岗位通过常规招聘渠道招到优质候选人的概率不高，尤其是在Harness Engineering还比较新兴的背景下。我身边跑通的做法有这么几个方向：一是在技术社区发布高质量的内容吸引被动求职者——很多优秀工程师不会主动投简历，但会因为在社区里看到你写的工程方案解析而产生兴趣，这时候一篇带有团队真实技术选型和踩坑记录的文章，比一个写得再好的招聘帖都有吸引力；二是对已有Agent开源生态的贡献者发起定向邀请，因为这些贡献者已经在实践中证明了自己对这个领域的热情和动手能力，而不是仅仅停留在会说概念的阶段；三是创业团队之间的"交叉引荐"，同行虽然存在竞争，但彼此也在相互关注，推荐过来的人常常是最靠谱的。5.2 三份评估表单，怎么看候选人而不是"感觉他很强"经常有创始人问我，面试的时候感觉候选人什么都答得上，但要做出判断就是没有抓手。这里分享一套实操下来效果不错的评估框架，分别对应技术、产品、市场三个岗位。技术岗的评估表有五个维度：模型行为意识、系统设计能力、失败排查思路、代码质量、沟通简洁度。每个维度按1到5分打分，但特别要注意的是——前两个维度的分数必须拉满才值得进入下一轮，后面三项哪怕普通一些也可以接受，因为这些能力可以在团队内部通过协作来弥补。产品岗的评估表则是另一个侧重点：场景拆解能力、交互设计中的不确定性处理、动手实测意愿、指标定义能力。其中"动手实测意愿"是很难培养的，缺乏这个特质的产品经理即使其他方面再优秀，放到Agent产品岗位上也会很别扭。市场岗的评估相对独特，关键维度包括：对开发者社区的理解深度、内容输出能力、技术方案的理解转化能力、以及数据敏感度。现实中很多市场岗候选人会在"内容输出能力"上失分——他可能做过大量传统营销活动，却从来没有写过一篇能被技术论坛认可的技术实践类文章。每轮面试结束后，当场做一次完整的打分并写一句"印象记忆点"，别拖到全部面试完再补。这不是走流程，而是防止你的判断被最后一件小事主导，这是我在实践中经常踩到的坑。5.3 创业团队的薪酬与激励：现金期权怎么分配才不埋雷预算有限是创业团队的常态，所以钱要花在刀刃上。给予核心的Harness工程师略低于市场水平的现金薪酬，但配给足够多的期权是常见做法，这个前提是对方真的认可方向。这里想特别提醒的是，技术团队里不要在期权分配上搞平均主义。控制层核心工程师拿到的期权比例最好是同级别普通工程师的1.8到2倍，因为他在系统积累上的不可替代性最强。而产品岗和市场岗因为决策可以相对频繁地调整，期权的集中度就不需要那么极端，但也要保证他的总回报预期在认可行业风险的前提下是可接受的。还有一个经常被忽略的点：现金薪酬的差距不要拉得过大。如果市场岗的现金收入比技术岗少非常多，跨岗位协作的时候会天然产生心理层级，造成"技术说什么产品只能执行"，这对Agent产品这种需要深度协同的团队是致命的。合理的结构是现金有梯度但不悬殊，期权拉开差距体现核心价值，两者叠加以后，让每个人都感觉自己拿到了一个公平的"总包"。6. 三拨人怎么共事：避免团队组建后的结构性内耗6.1 需求流：用"场景卡片"取代长篇PRD我对产品团队有一个硬性要求：所有新功能的需求描述，最终都要压缩成一张结构清晰的场景卡片，而不是几十页的PRD文档。场景卡片只有四个字段——目标用户与触发场景、用户当前遇到的阻碍、Agent需要执行的动作链路、成功标准与验收指标。这里不是要求每个卡片里的信息都要完整详尽，而是用统一的格式把决策成本降到最低。为什么这样做？因为Agent产品的开发过程高度依赖产品与技术之间的快速对齐。工程师拿到传统PRD后，通常需要花大量时间自行理解场景再翻译成系统逻辑，这个环节的信息损耗往往极大。而一张场景卡片能让技术同事用最短时间判断"这个需求应该落在Prompt层、工具函数层，还是UI交互层"，在会议中就能给出排期评估。我在A团队的实验表明，实施场景卡片之后，需求从提出到进入开发的周期压缩了将近一半。这不是什么魔法，只是消除了信息翻译过程中那些来回确认的等待时间。6.2 技术流：评测看板必须成为所有人开会依赖的数据底座当一个团队同时有技术、产品和市场三条线时，语言体系天然分裂：技术谈架构，产品谈交互，市场谈用户反馈，而Agent产品的质量本质上是一个跨三者的复合命题。把这三者串起来的关键，是评测看板——一套由质量层工程师维护、所有角色都会打开看的数据面板。看板上至少要有这几个维度：核心任务成功率（如"正确完成工具调用并生成最终答案"）、工具调用失败的首要原因归类（模型参数错误、超时、工具本身Bug）、各场景平均轮次和耗时、以及多轮对话中的信息遗忘率。产品经理在需求评审时用这些数据论证优先级，技术负责人在迭代规划时用它们衡量优化效果，市场同事在与客户沟通时把它们变成产品能力的客观素材。每周固定一次"评测会"——不是正式述职，而是所有人对着看板聊"这个失败率为什么反弹了"。这个习惯一旦养成，团队共识就自然形成，三拨人不会再各说各话。6.3 冲突流：当产品和技术对"模型能力边界"的判断不一致时这种冲突在Agent团队里的发生频率远高于传统软件团队。典型场景是：产品希望Agent能在一次对话里完成"解析合同->提取风险条款->生成修订建议"三个环节，技术评估后认为当前模型的上下文处理能力无法稳定支撑，但产品认为用户需求就应该被完整满足，不能拆成三步割裂的对话。过去处理这类分歧时，大家通常会议论"谁的判断更准确"。事实上在早期阶段，模型的真实能力边界本身就是一个动态变化的对象，产品和技术各自都只有部分信息。更务实的办法是用一个分层妥协方案来推进：第一层由系统预设一个可以覆盖全流程的Prompt框架，第二层在每一步工具调用后加入上下文摘要环节来做记忆压缩，第三层在UI上提供"分阶段执行"的降级选项，让用户选择是自动串联还是逐步确认。大多数这类分歧都能在这个三层机制里找到共同落点，实在找不到再上升讨论范围，而不是停留在"谁对谁错"的意气之争上。7. 关于初创团队组建的最终几点体会回想我带过和旁观过的几个Agent创业团队，一个很深的感触是：技术、产品、市场这三类人之间的摩擦，本质上是视角的摩擦，而不是人的摩擦。技术人看到的Agent是一个概率系统，产品人看到的是用户信任，市场人看到的是行业风口，三方都没有错，但如果没有人把这三种视角拧成一股绳，团队就会散成一盘棋。我自己在实操中的几条经验，最后分享在这里：第一，把评测体系当作团队组建后的第一个共同交付物。技术、产品、市场三个角色只有围绕同一套数据建立共识，协作才会变得顺滑。技术通过它证明优化有效，产品通过它建立迭代节奏，市场通过它对外讲故事，三方都受益于这套底座。第二，早期宁可让产品经理多动手碰模型，也不要让他只做需求翻译和排期。Agent产品经理的直觉是在一次次的实测中养成的，这种直觉是任何规模、任何级别的团队协作都替代不了的。如果产品经理从头到尾不实际运行一次Agent，他设计的每一个交互方案都是在隔靴搔痒。第三，市场角色不要被锁死在"对外发声"，他在团队内部的信息枢纽意义往往比创造的外部传播价值更大。把用户声音通过他系统性地回流到技术与产品侧，整个团队的迭代方向才会更贴近真实需求，少走很多自嗨的弯路。最后再讲一个实用的技巧：在新成员加入的头三十天，让他独立负责一个完整的端到端小任务，技术岗就让他搭一个从Prompt到评测的完整闭环，产品岗就让他把某一个场景从卡片推进到上线，市场岗就让他独立发起一场社区活动并收集回访数据。这个"首月闭环"的做法比任何入职培训都更能检验一个候选人的真实成色，同时也能让团队在非常短的时间里看到新成员的思考方式和行为惯性，尽早发现匹配度问题。AI Agent Harness Engineering的创业窗口期还很长，但窗口期的红利属于那些能快速把队伍拉起来、把协作跑顺、把产品扎进真实场景的团队。希望这篇关于人才配置的复盘，能帮你少一些我在组建过程中走过的弯路。