企业官网建设流程全解析

1. 这个项目到底在解决什么问题

第一次看到 agency-agents 这个项目名的时候，我以为又是一个把 GPT 包一层壳的套话工具。点进去翻了翻源码和目录结构，发现思路确实不太一样——它做的事情，是把不同职业里那些"老手才知道"的工作经验，拆成结构化的指令集，塞进一个个独立的 AI Agent 里，让每个 Agent 只专注干一件事，而且干得像那个职业的人。

举个最直观的例子。你让一个通用大模型帮你写一份项目复盘，它大概率会给你"背景-过程-结果-反思"这种四平八稳的模板。但如果你把这份任务交给一个被灌入了"十年项目经理经验"的 Agent，它可能会先反问你三个问题：这个项目的关键干系人是谁、验收标准有没有在启动阶段就锁死、延期是发生在关键路径上还是非关键路径上。这就是职业经验带来的差异——不是知识量的差异，而是提问方式和判断优先级的差异。

agency-agents 的核心价值就在这里。它不追求做一个什么都能干的超级助手，而是把"职业经验"这个抽象的东西，拆解成可复用的 Agent 配置。每个 Agent 有自己的角色设定、工作流程、输出规范、甚至"踩坑清单"。你可以把它理解成一个职业经验的模块化仓库，需要哪个职业的视角，就调用哪个 Agent。

这个项目适合谁看？我觉得有三类人值得花时间研究。第一类是正在做 AI 应用落地的开发者，尤其是想把大模型能力嵌入到具体业务流程里的，这个项目的 Agent 拆分思路可以直接借鉴。第二类是对 Prompt Engineering 有进阶需求的人，项目里每个 Agent 的指令写法都值得逐字拆解。第三类是做知识管理或者流程标准化的从业者，因为这套方法本质上是在把隐性经验显性化。

2. 项目整体架构与设计思路拆解

2.1 为什么选择"按职业拆分"而不是"按任务拆分"

市面上大多数 Agent 框架是按任务类型拆的——写作 Agent、编程 Agent、数据分析 Agent。这种拆法有个问题：同一个任务，不同职业的人做法完全不同。写一份需求文档，产品经理写出来和项目经理写出来，结构、侧重点、甚至用词都不一样。

agency-agents 选择按职业拆分，背后的逻辑是：职业本身就是一套经过长期验证的问题解决框架。一个职业之所以存在，是因为它在特定场景下形成了稳定的工作方法和判断标准。把这些方法固化到 Agent 里，比让模型自己"悟"要可靠得多。

我翻了一下项目的目录结构，每个 Agent 基本都包含这几个部分：

• 角色定义：这个 Agent 是谁，有什么背景，擅长什么，不擅长什么
• 工作流程：接到任务后按什么顺序推进，每一步的输入输出是什么
• 判断标准：什么算做好了，什么算没做好，边界在哪里
• 输出规范：交付物的格式、粒度、必须包含的要素
• 常见陷阱：这个职业最容易犯的错误，以及如何避免

这个结构其实很像一份岗位说明书加操作手册。区别在于，它是写给 AI 看的，所以每一条都必须足够具体、可执行、无歧义。

2.2 Agent 之间的协作机制是怎么设计的

单个 Agent 能力再强也有边界。agency-agents 有意思的地方在于，它设计了一套 Agent 之间的协作协议。比如一个"产品需求评审"场景，可能会同时调用产品经理 Agent、技术负责人 Agent、测试工程师 Agent，让它们从各自视角对同一份需求提出意见。

协作机制的核心是角色隔离加信息同步。每个 Agent 只从自己的职业视角出发，不越界替别人做判断。但它们共享同一份上下文信息，所以能形成互补而不是互相干扰。

我实测下来，这种设计在复杂决策场景下效果很明显。你让一个通用模型同时考虑产品、技术、测试三个维度，它往往会给出一个"和稀泥"的答案，每个维度都提一点但都不深入。而三个独立 Agent 各自输出后，你再做整合，得到的是一份有真实分歧、有取舍依据的决策参考。

2.3 和直接写 Prompt 相比，优势在哪里

有人可能会问：我直接写一段详细的 Prompt 不也能达到类似效果吗？为什么要用这个项目？

区别在于可维护性和可复用性。直接写 Prompt 的问题是，每次遇到新场景都要重新调，而且调好了很难沉淀。agency-agents 把每个职业的经验做成了独立模块，你可以像搭积木一样组合。今天做电商项目，调用电商运营 Agent 加供应链 Agent；明天做教育项目，换成教研 Agent 加课程设计 Agent。模块本身不需要改，只需要换组合方式。

另一个优势是版本管理。职业经验是会更新的，今天有效的做法明天可能就过时了。把经验写在 Agent 配置里，可以单独更新某个 Agent 而不影响其他部分。这比维护一个巨大的 Prompt 库要清晰得多。

3. 核心细节解析与实操要点

3.1 一个 Agent 配置文件的完整拆解

我拿项目里一个"用户研究"方向的 Agent 配置来举例，说明一个高质量的 Agent 应该包含哪些细节。

首先是角色定义部分。它不会只写"你是一个用户研究员"，而是会写清楚：你有五年以上定性研究经验，擅长深度访谈和可用性测试，你的工作原则是"先理解再验证"，你不对产品方案本身发表意见，只对用户行为和认知模式做判断。这几句话的作用是划定能力边界，防止 Agent 在超出自己职业范围的问题上乱给建议。

然后是工作流程。用户研究 Agent 的流程通常是：明确研究目标 → 选择研究方法 → 设计研究工具 → 执行数据收集 → 分析并输出洞察。每一步都有具体的检查点。比如"明确研究目标"这一步，Agent 会被要求确认：这个研究要回答的核心问题是什么、决策者是谁、研究结果会影响什么决策、时间盒是多长。这些问题不回答清楚，就不进入下一步。

判断标准部分最有意思。它会明确写出什么算好的用户洞察：必须基于可观察的行为而不是用户的自述、必须能解释"为什么"而不只是"是什么"、必须能指向具体的设计或策略调整。这三条标准直接决定了 Agent 输出的质量下限。

3.2 指令写法中的几个关键技巧

翻完十几个 Agent 配置后，我总结出几个反复出现的指令写法技巧，这些技巧可以直接迁移到自己的项目里。

第一个技巧是用否定句划定边界。好的 Agent 配置里，"不要做什么"和"要做什么"同样重要。比如"不要在没有数据支撑的情况下给出结论"、"不要用行业黑话替代具体描述"、"不要假设用户知道背景信息"。否定句的作用是防止模型滑向它最擅长的"泛泛而谈"。

第二个技巧是把抽象要求翻译成可检查的动作。不说"要深入分析"，而说"至少从三个不同角度分析，每个角度必须引用具体数据或案例"。不说"要简洁"，而说"每个要点不超过三句话，总篇幅不超过一页"。可检查意味着可执行。

第三个技巧是预设追问路径。很多 Agent 配置里会写：如果用户提供的信息不足以完成任务，你应该按以下顺序追问……这相当于给 Agent 装了一个"信息缺口检测器"，让它主动补全必要信息，而不是硬着头皮瞎编。

3.3 实操中容易踩的坑

注意：Agent 配置不是越长越好。我见过有人把一个 Agent 的指令写到三千多字，结果模型反而抓不住重点。经验值是单个 Agent 的核心指令控制在八百到一千二百字之间，超出的部分拆成参考文档按需加载。

另一个坑是角色冲突。如果你同时激活两个职责有重叠的 Agent，比如"项目经理"和"产品经理"，它们可能会在优先级判断上打架。解决办法是在协作协议里明确谁在什么阶段有最终决定权，或者干脆分阶段调用，不要同时激活。

还有一个容易被忽略的问题是输出格式的稳定性。Agent 配置里如果只写"输出一份报告"，每次生成的格式可能都不一样。必须明确指定：用什么结构、分几个部分、每个部分包含什么要素、是否需要用表格、字数范围是多少。格式越具体，输出越稳定。

4. 实操过程与核心环节实现

4.1 从零搭建一个自定义 Agent 的完整步骤

假设你要做一个"技术方案评审"方向的 Agent，下面是完整的搭建过程。

第一步是经验采集。找两到三位有五年以上经验的技术负责人，问他们同一个问题：拿到一份技术方案，你最先看什么、最担心什么、什么情况下会直接否决。把他们的回答整理成原始素材。这一步的关键是问"判断依据"而不是问"标准流程"，因为流程可以查文档，判断依据才是隐性经验。

第二步是模式提取。把收集到的回答做归类，找出反复出现的判断维度。比如可能归纳出：方案是否解决了真实问题、技术选型是否有过度设计、失败场景是否有预案、团队是否具备落地能力。这四个维度就构成了 Agent 的核心评审框架。

第三步是指令编写。按角色定义、工作流程、判断标准、输出规范、常见陷阱五个部分来写。工作流程部分要具体到每一步的输入和输出。比如"第一步：确认方案要解决的核心问题，输出一句话问题定义，如果无法用一句话说清楚，标记为高风险"。

第四步是测试与迭代。拿三到五份真实的技术方案让 Agent 评审，对比它给出的意见和人类专家的意见。差异大的地方就是指令需要细化的地方。我自己的经验是，第一版 Agent 通常只能达到人类专家六成左右的水平，迭代三到四轮后能到八成以上。

4.2 多 Agent 协作的配置方法

单 Agent 跑通之后，可以尝试多 Agent 协作。配置方法不复杂，核心是定义清楚三件事：谁参与、按什么顺序发言、分歧怎么处理。

以"需求评审"为例，可以配置产品经理 Agent 先陈述需求背景和用户价值，然后技术负责人 Agent 从实现成本和风险角度给出评估，接着测试工程师 Agent 从可验证性角度提出质疑，最后项目经理 Agent 综合各方意见给出决策建议。

分歧处理机制我建议用显式分歧记录。当两个 Agent 的判断不一致时，不要强行让它们达成一致，而是把分歧点、各方理由、需要补充的信息记录下来，交给人类决策者。这比让 AI 假装达成共识要有价值得多。

4.3 参数调优与效果评估

Agent 的效果受几个参数影响比较大。温度参数建议设在 0.3 到 0.5 之间，太低会死板，太高会跑偏。最大输出长度要根据任务类型调整，分析类任务需要留足空间，格式类任务可以收紧。

效果评估我常用一个简单方法：准备十道有标准答案的测试题，让 Agent 回答，统计准确率和完整率。准确率看它有没有说错，完整率看它有没有漏掉关键点。两个指标都达到八成以上，这个 Agent 才算可用。

5. 常见问题与排查技巧实录

5.1 Agent 输出质量不稳定的排查思路

输出质量忽好忽坏是最常见的问题。排查顺序建议从下往上：先看输入信息是否充分，再看指令是否有歧义，最后看模型本身的能力边界。

输入信息不充分的表现是 Agent 频繁追问或者给出笼统回答。解决办法是在调用前先做一次信息完整性检查，把必要信息补齐再交给 Agent。

指令歧义的表现是同一个任务每次输出的结构不一样。解决办法是把所有抽象要求翻译成可检查的具体动作，前面已经说过，这里不重复。

模型能力边界的问题比较难处理。有些任务就是超出了当前模型的能力范围，比如需要大量实时数据支撑的判断。这种情况要么换任务，要么给 Agent 补充外部数据源。

5.2 常见问题速查表

5.3 几个我踩过的坑和对应的解法

第一个坑是过度依赖 Agent 的自我判断。早期我让 Agent 自己决定什么时候任务完成了，结果它经常在信息还不充分的时候就给出结论。后来改成显式定义完成标准，比如"必须包含至少三个可验证的假设"、"必须列出两个以上风险点"，输出质量立刻稳定了。

第二个坑是忽略 Agent 之间的信息传递损耗。多 Agent 协作时，前一个 Agent 的输出会作为后一个 Agent 的输入。如果前一个 Agent 的输出格式不固定，后一个 Agent 的理解就会出偏差。解法是在协作协议里定义统一的信息交换格式，每个 Agent 的输出都必须符合这个格式。

第三个坑是把 Agent 当成万能工具。有些任务本质上不适合用 Agent 做，比如需要实时数据、需要物理世界交互、需要高度创造性突破的。强行用 Agent 做，效果还不如人工。判断标准很简单：如果这个任务人类专家也需要大量外部信息才能完成，那 Agent 大概率也做不好。

6. 这个项目给我的几点启发

研究完 agency-agents 之后，我最大的感受是：AI 应用的价值不在于模型本身有多强，而在于你把什么经验灌进去了。同样的底层模型，灌入不同职业的经验，就能变成完全不同的工具。这有点像游戏里的角色养成，底子是一样的，但技能树点法不同，定位就完全不同。

另一个启发是关于知识管理的。我们平时说的"经验沉淀"，往往停留在写文档、做分享这个层面。但文档是死的，分享是一次性的。把经验做成 Agent，意味着它可以被反复调用、持续迭代、组合使用。这可能是知识管理的一个新方向。

如果你也想动手试试，我的建议是从自己最熟悉的领域开始。找一个你做了很多年、有很多"直觉判断"的场景，试着把这些直觉拆解成可执行的步骤和可检查的标准。这个过程本身就会让你对自己的经验有新的认识。至于 agency-agents 这个项目，它的价值不在于代码有多复杂，而在于它提供了一套把隐性经验显性化的方法论，这套方法论可以迁移到很多不同的场景里。