用工程思维部署编码智能体：构建闭环软件工厂
It's time to apply a true engineering mindset to deploying coding agents. There’…
It's time to apply a true engineering mindset to deploying coding agents. There’s too much hand-waving around what agents are best, which models to use, and how to optimize ROI from coding agents over time. The solution is to set up a closed-loop system in the cloud where all of your agents are tracked and measured against your own data and workflows, so you can adjust your setup based on actual data and not vibes.
是时候以真正的工程思维来部署编码代理了。关于哪种代理最好、该用哪些模型，以及如何长期优化编码代理的投资回报率，存在太多空谈。解决方案是在云端建立一个闭环系统，让所有代理都根据你自己的数据和工作流程进行追踪和衡量，这样你就能基于实际数据而非感觉来调整你的配置。
The emerging category of infrastructure that supports this approach is the cloud software factory. Software factories are automation loops around the SDLC, comprised of agents that triage, spec, implement, verify, review, monitor, etc. Done right, these factories allow for measurement, improvement and automation over time, and can help prove that you are doing agentic engineering the right way.
支持这种做法的新兴基础设施类别是云软件工厂。软件工厂是围绕软件开发生命周期的自动化循环，由负责分诊、规格制定、实施、验证、审查、监控等任务的代理组成。如果做得好，这些工厂能够实现长期的衡量、改进和自动化，并有助于证明你正在以正确的方式开展代理工程。
Factories should follow these design principles:
工厂应遵循以下设计原则：
- Factories should be defined as code, version-controlled, and have their definitions editable by agents. - Factories must live in the cloud to support team access, central data storage, and automations. - Factories should have a runtime that is API driven, not UI first. - Factories should come with built-in evals, improvement loops and benchmarks so you can ensure improvement over time. - Factories should be inherently multi-model and multi-agent, so they can take advantage of improvements in models and harnesses.
- 工厂应被定义为代码，进行版本控制，并且其定义可由代理编辑。 - 工厂必须部署在云端，以支持团队访问、集中数据存储和自动化。 - 工厂的运行时应该以API驱动，而非UI优先。 - 工厂应内置评估、改进循环和基准测试，以确保你能随时间不断改进。 - 工厂应天然支持多模型和多代理，以便利用模型和工具链的改进。
Your goal is getting to a “closed-loop” factory: one where all of the data, observability and improvement features are baked in, so that agents (and humans) can use that data to improve the factory over time.
你的目标是实现一个“闭环”工厂：所有数据、可观测性和改进功能都内置其中，这样代理（以及人类）就能利用这些数据来持续改进工厂。
That last point on data collection and self-improvement is especially important to get right. If you’ve set up your factory properly, these agents take their learnings and propose changes to how the factory operates. They do this by creating diffs against the factory definition, which – assuming your factory is defined as code – is easy for them to change.
最后一点关于数据收集和自我改进尤其需要做对。如果你正确设置了工厂，这些代理会吸取经验教训，并提出改变工厂运作方式的建议。它们通过针对工厂定义创建差异来实现这一点——假设你的工厂被定义为代码，那么对它们来说修改起来很容易。
The high-level flow for self-improvement comes in three steps:
自我改进的高层流程分为三个步骤：
1. Factory agents do triage, implement, verify, etc. – they build the product. 2. Scorer agents periodically grade that work along dimensions that you define, like cost, quality, verbosity, etc. 3. Self-improvement agents review scores and suggest improvements. Humans review those suggestions as PRs on the factory definition and merge improvements.
1. 工厂代理执行分诊、实施、验证等任务——它们构建产品。 2. 评分代理定期按照你定义的维度（如成本、质量、冗长程度等）对工作进行评分。 3. 自我改进代理审查评分并提出改进建议。人类以工厂定义上的拉取请求形式审查这些建议，并合并改进。
The way to think about the factory approach is as meta-engineering. You should invest now in infrastructure that lets you measure, test and automatically improve the SDLC. The longer you wait, the more catch-up you will have to do and the more tokens you’ll burn in the meantime. Building this infra is possible, but a big endeavor, so as you evaluate factory platforms you should look for ones that have the right primitives to help you scale software development today.
思考工厂方法的方式是将其视为元工程。 你现在就应该投资于能够让你衡量、测试并自动改进SDLC的基础设施。你等待的时间越长，需要追赶的就越多，期间消耗的令牌也就越多。构建这样的基础设施是可能的，但这是一项巨大的工程，因此，在评估工厂平台时，你应该寻找那些具备正确原语、能帮助你今天扩展软件开发规模的平台。
If you're team is building a software factory, let's get in touch: http://warp.dev/factories/request-access
如果你的团队正在构建软件工厂，请联系我们：http://warp.dev/factories/request-access
更进一步：量化金融体系
看懂新闻只是起点——沿量化金融路径，把它变成能交付的工程能力